Open taiphuong1 opened 6 months ago
https://github.com/codeforboston/home-energy-analysis-tool/blob/summary-outputs/rules-engine/src/rules_engine/pydantic_models.py is where our schema is, you can get a flavor for some of the language we use for the fields in the excel sheet.
https://dbdiagram.io/ is a free, neat tool to create database diagrams if that might help folks visualize the proposed schema.
@alanisaac this is helpful. It looks like we have been working on similar ideas. It will be helpful to coordinate. We can standardize on your names, if preferred. The idea of the schema is just for data to be persisted now. We can add calculated data (for example the number of days between 2 dates) later.
I tried the dbdiagram.io tool - its nice.
Here is a diagram I put together. The premise is that there could be multiple cases for the same location.
The fuel usage table is to reflect the monthly usage readings from the energy bill.
This is a starting point - so open for revision and discussion.
It's nice that the tool creates SQL too.
I don't think we need a phone number, or maybe I'm wrong. @stevebreit
In ENERGY_USE_PERIOD we can probably avoid persisting usage_days
as that is just end_date - start_date
I am not clear what these fields in ENERGY_USE_PERIOD represent:
included_automatically
exclusion_manually
inclusion_manually
standard_deviation_of_heat_loss_rate
is better than Standard_deviation_ua
and
standard_deviation_of_heat_loss_rate
is better thanStandard_deviation_ua
Energy Use Parent Class => Delivery Period Subclass (date of delivery and quantity) => Billing Period Subclass (start/number of days, end, and quantity)
Michelle's Beta 1 (and always): Export data format that can be re-ingested again
Notes from Javascript team breakout about where we're at on this issue: Jeff's Posed Goal for this moment/persistence team:
Rules engine has it's ideas.
Michelle:
heat-stack/_heat ~~~~> /
(e.g. Terms and Conditions)
All homes /all-homes
heat-stack/_Home
~~~~>/home/1245/*
My page /me
Rules engine has its ideas.
When we discussed this last week, I wanted to put together a proposal that maps to what we have in the rules engine. I haven't had a ton of time, but I thought I'd spend part of today's session putting that proposal together. Here it is in DBML.
Table case {
id integer [primary key]
home_id integer [ref: > home.id]
created_at timestamp
last_updated_on timestamp
first_name varchar
last_name varchar
// case worker info?
}
Table location {
id integer [primary key]
address varchar
address_line_2 varchar
city varchar
state varchar
zip varchar
country varchar
}
Table home {
id integer [primary key]
location_id integer [ref: > location.id]
// summary inputs
living_area float
fuel_type integer
design_temperature_override float
heating_system_efficiency float
thermostat_set_point float
setback_temperature float
setback_hours_per_day float
// domestic hot water inputs
number_of_occupants integer
estimated_water_heating_efficiency float
stand_by_losses float
}
Table heat_load_analysis {
id integer [primary key]
home_id integer [ref: > home.id]
rules_engine_version varchar
estimated_balance_point float
other_fuel_usage float
average_indoor_temperature float
difference_between_ti_and_tbp float
design_temperature float
whole_home_heat_loss_rate float
standard_deviation_of_heat_loss_rate float
average_heat_load float
maximum_heat_load float
}
Table natural_gas_bill {
id integer [primary key]
case_id integer [ref: > case.id]
provider varchar
}
Table natural_gas_bill_records {
natural_gas_bill_id integer [ref: > natural_gas_bill.id]
period_start_date datetime
period_end_date datetime
usage_therms float
inclusion_override integer
}
Table oil_propane_bill {
id integer [primary key]
case_id integer [ref: > case.id]
provider varchar
preceding_delivery_date datetime
}
Table oil_propane_bill_records {
oil_propane_bill_id integer [ref: > oil_propane_bill.id]
period_end_date datetime
gallons float
inclusion_override boolean
}
case
from the data needed for the home analysis. home
table (see the "DHW" tab in the Heat Load Analysis Tool spreadsheet)design_temperature
to an output in heat_load_analysis
rather than an input. Since we decided to pull temperature data for locations instead of selecting a weather station, IIRC this will be calculated based on the home location (unless using the override), but I am double-checking with @stevebreit.*_bill
), and one to store the billing period records associated with that statement (*_bill_records
). The bill
table lets us store additional information about the energy provider, as well as supports the idea that oil / propane needs one extra field for the preceding delivery date (cell B6 in the spreadsheet).natural_gas_*
vs oil_propane_*
. I know it means more tables, but the differences that already exist between the two types of energy may not be the only ones. In our last meeting @stevebreit made mention of some other strange scenarios specific to energy types in the past that may become more common and have a need to be represented officially as the tool scales up. This is the way we represent the data in the rules engine as well.
-- Edited by group on Dec 26 to harmonize HOME and HeatingLoadAnalysis here, with rules engine and spreadsheet
Note: This table represent a single location (ie. a house)
Note: This is the main table for each case, referencing a location associate with the location_id FK
~Telephone~
Note: This table holds the data for usage csv for each case referencing the case_id FK