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.

DocDataPoint

class rhizome.models.datapoint_models.DocDataPoint(*args, **kwargs)[source]

For Validation of upload rhizome.

Document Models

Document

class rhizome.models.document_models.Document(*args, **kwargs)[source]

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.

Document.transform_upload()[source]

document.refresh_master()

This method takes the data for a document, and takes the source submissions ( rows in a csv ), maps them and syncs them to the DataPoint Table.

Document.refresh_master()[source]

SourceSubmission

class rhizome.models.document_models.SourceSubmission(id, document, instance_guid, row_number, data_date, location_code, campaign_code, location_display, submission_json, created_at, process_status)[source]

SourceObjectMap

class rhizome.models.document_models.SourceObjectMap(id, master_object_id, master_object_name, source_object_code, content_type, mapped_by)[source]

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.

Location Models

Location

class rhizome.models.location_models.Location(*args, **kwargs)[source]

A point in space with a name, location_code, lat/lon, and parent location id. The parent location id is used to create the tree used to create aggregate statistics based on the information stored at the leaf level.

LocationPolygon

class rhizome.models.location_models.LocationPolygon(*args, **kwargs)[source]

A shape file when avaiable for a location.

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
  1. 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 and agg_datapoints for a particular campaign. Campaign data is taken from the datapoint table and via these two methods upserted into the DataPointComputed 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

class rhizome.models.campaign_models.AggDataPoint(id, indicator, location, campaign, value)[source]
class rhizome.models.campaign_models.DataPointComputed(id, value, indicator, location, campaign)[source]

Dashboard Models

Custom Chart

class rhizome.models.dashboard_models.CustomChart(*args, **kwargs)[source]

A table containing a configuration used by the front end to construct a chart for a particular set of data. Charts, have titles and UUIDs, as well as a chart_json field in which the chart configuration is stored.

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.