Data Model¶
Datapoint Models¶
DataPoint
¶
-
class
rhizome.models.datapoint_models.
DataPoint
(*args, **kwargs)[source]¶ The core table of the application. This is where the raw data is stored and brought together from data entry, ODK and csv upload.
Note that this table does not store the aggregated or calculated data, only the raw data that we get from the source.
The source_submission shows the original source of the data in the source_submission. The source_submission is -1 in the case of data entry.
Document Models¶
Document
¶
document.transform_upload()¶
This method takes a file and moves the file data into the source_submission
table which stores one row in the table for one row in the CSV.
SourceSubmission
¶
Indicator Models¶
Indicator
¶
-
class
rhizome.models.indicator_models.
Indicator
(*args, **kwargs)[source]¶ - The type of data that we are tracing, for instance
- Number of children missed due to religious locations
- Number of vaccinators paid on time
- Number of iVDPV cases
- Percentage of children missed due to religious locations.
Note that both calculated and raw indicators are stored in this table. For more information on how indicicators are used to calculated data for more indicators take a look at the CalculatedIndicatorComponent model.
Campaign Models¶
Campaign
¶
-
class
rhizome.models.campaign_models.
Campaign
(*args, **kwargs)[source]¶ A grouping of rhizome. For polio, for we have a “campaign type” of “National Immunization Day” or “Mop Up” which means an immeiate response to a case by conncentrated vaccination campaigns in that area.
The campaign thus allows you to model these two things with the model in these two instances:
1. NID - Happens monthly for the Endemics. We have a certain type of Inticators that we want to collect for this.. see “Management Dashboard.”
- indicator_list = Management Dashboard Indicators
- top_lvl_location = Afghanistan
Mop Up - Could happen anywhere where low immunity, for instance Ukraine.
- indicator_list = A few select Indicators related to the “mop up”
effort. These will be different, put potentially overlapping from the NID indicator list. - top_lvl_location = Ukraine
For other efforts, this model can be useful.. For Routine Immunization one could imagine a similar setup.
The campaign model has a method called “get_datapoints”, which gets the relevant raw and aggregated datapoints for a given campaign. The data is aggregated from the date, indicator_list and location in the AggRefresh.
The indicator_list, is determined by taking the flatened top lvl indicator tree that is for the campaign.
-
Campaign.
aggregate_and_calculate
()[source]¶ Calls
agg_datapoints
andagg_datapoints
for a particular campaign. Campaign data is taken from the datapoint table and via these two methods upserted into theDataPointComputed
model.
-
Campaign.
agg_datapoints
()[source]¶ Regional Aggregation based on the adjacency list built on top of the parent_location_id column.
Data stored in the DataPoint table for a location with the same indicator, campaign will always override the aggregated values, that is if the indicator is an integer ( summing percents and booleans regionally doesnt make sense.)
Here, we create a tuple_dict in which the unique key of (locaiton, indicator, campaign) represents the key, and the cooresponding value is the value. This way we add to the dict the aggregated values, then iterrate through the raw values, adding or updating the data in the tuple dict before bulk inserting the data.
The tuple looks like: {(1, 201, 164): 12, (2, 101, 168): .24}
-
Campaign.
calc_datapoints
()[source]¶ When the agg_datapoint method runs, it will leave the agg_datapoint table in a state that all of the rows that were altered, and need to be cached thats is the
calc_refreshed
column will = ‘f’ for all of the rows that this task effected.To find out more about how calculation works, take a look at the fn_calc_datapoint stored procedures
Dashboard Models¶
Custom Chart
¶
Custom Dashboard
¶
-
class
rhizome.models.dashboard_models.
CustomDashboard
(*args, **kwargs)[source]¶ A table containing all of the custom dashboards in the system. The data in teh dashboard_json field is how the FE is able to draw and render the specific vizulaizations. If inserted via POST the application will validate the json, but if you insert directly in the table it will not.