Reference Tables vs Scenarios

Datagration has three very robust and performant mechanisms for storing data:

1) workspace signals

2) Scenarios

3) Reference Tables

The data storage mechanism you choose will depend on project objectives and other data model architecture considerations. However, the three storage mechanisms offered in the Datagration platform provide significant flexibility to tailor the platform to the needs of any project.

1) Using workspace signals and scenarios together: it is not uncommon to have projects that separately store monthly and daily data (such as production data), meaning information has different granularity. For example, PetroVisor's standard " produced gas per time increment" signal can only hold one scope interval of data (monthly or daily, but not both). One option is create a second separate signal, such as " produced gas per time increment (daily)", and store the daily data in that second signal. The disadvantage to this approach is that you have to create the second signal, and manage that new signal name within the workspace architecture. This can become somewhat cumbersome if you also have signals for budgets, reserves forecasts, and any number of other versions of the same type of data.

 This is where a Scenario can make workspace management easier and simplify the architecture of the workspace. Consider a Scenario as a sub-workspace inside the main workspace. When a Scenario is added to a workspace, it inherits all the signal definitions of the main workspace, meaning that all signals used in the main workspace are also available in the Scenario. Adding a Scenario in the workspace is simple in the Web App.

Continuing with the example above for storing monthly and daily gas production data, the Scenario called " Daily Data" can store the daily-scoped gas production in the signal called "produced gas per time increment" within the " Daily Data" scenario. Note that the signal name is the same, but it's location is now inside the " Daily Data" scenario and not in the main workspace. This separates the monthly gas production data from the daily gas production data without having to create a separate data signal.

You can access the data inside a scenario through a number of P# methods from the PetroVisor Web App. Scenario names can be included explicitly in contexts of P# scripts, or you can use a family of ScenarioSignalValue() functions to directly reference signal data inside a Scenario. 

2) Reference tables: the standard PetroVisor data storage model is for data that is either static, time-series or depth-series. For time-series and depth-series data, the time or depth intervals must be uniform. For example, monthly has to fall on the 1st day of the month (1/1/2023, 2/1/2023, etc.). Data every 15 mins has to fall on quarter-hour intervals. Depth data has to be every foot, or every meter, etc.

Reference tables have no such limitation. Reference tables can store unstructured data, which is suitable for information that does not occur on even time or depth intervals. Reference tables can also store data without an entity or date/time stamp, making it ideal for high-frequency data of all kinds, such as directional surveys, financial accounting transaction data (which might have multiple transactions on the same day for the same entity), and production-based type curves using a normalized time scale. Transaction data is another use case.

Reference Tables do require a unique key for each row in the reference table. Every Reference Table includes a Key column with is combined with the Entity and Date/Time columns to create the key for each row. This must be unique. If either Entity or Date/Time are not part of the Reference Table, then the Key column itself may need to be unique for each row in the Reference Table.

When using Reference Tables, the Key column should be created in such a way that it can be easily referenced in a P# script via a computed column when you want to retrieve that data later.

There are two P# functions that can retrieve Reference Table data: RefTableValueAsString() and RefTableValueAggregatedAsString(). Please refer to the Knowledge base articles for these P# functions for more information on how to retrieve data from Reference Tables.