Feature/epdm models: create fct and dim tables for performance-based assessment of educator candidates

[oscarrezab]

Description & motivation

Three models for EPDM data. Done as part of summer intern final project, with the hope of answering analytics questions from the SCDE. It is part of this Jira epic.

PR Merge Priority:

• Low

New files created:

• dim_candidate.sql: dimension table to describe an educator candidate
• dim_candidate.yml: YAML to describe table above
• dim_performance_evaluation.sql: dimension table to describe a performance evaluation
• dim_performance_evaluation.yml: YAML to describe table above
• fct_candidate_assessment.sql: fact table to describe the event of a performance evaluation for a given educator candidate, including rating and results
• fct_candidate_assessment.yml: YAML to describe table above

Tests and QC done:

• Executed successful dbt project run in TX stadium.

edu_wh PR Review Checklist:

Make sure the following have been completed before approving this PR:

• Description of changes has been added to Unreleased section of CHANGELOG.md. Add under ## New Features for features, etc.
• If a new configuration xwalk was added:
  • The code is written such that the xwalk is optional (preferred), and this behavior was tested, OR
  • The code is written such that the xwalk is required, and the required xwalk is added to edu_project_template, and this PR is flagged as breaking change (not for patch release)
  • A description for the new xwalk has been added to EDU documentation site here
• If a new configuration variable was added:
  • The code is written such that the variable is optional (preferred), and this behavior was tested, OR
  • The code is written such that the variable is required, and a default value was added to edu_project_template, and this PR is flagged as breaking change (not for patch release)
  • A description for the new variable has been added to EDU documentation site here
• Reviewer confirms the grain of all tables are unchanged, OR any changes are expected, communicated, and this PR is flagged as a breaking change (not for patch release)

• Build the other models related to this project.

[rlittle08]

I think this messes with the grain by creating duplicates, since stg_performance_evaluation_ratings can have more than one record per k_performance_evaluation. But also, are you using any actual information from ratings here?

Looking closer, I think performance evalutions -> dim, but performance_evaluation_ratings -> fct. They should not both be included here.

I see how you got here, though. The terminology Ed-Fi uses for these two resources is confusing..

[rlittle08]

in general, the from table should be the 'many' in 'many-to-one' joins, eg from stg ... join dim. This is a logical flow because the grain is defined by the 'many' table, then we tack on extra information without changing the grain via dims

[rlittle08]

what are the pros/cons to having a fct_candidate_assessment vs. a more generic fct_performance_evaluation_ratings that could be linked to any kind of person?

[rlittle08]

no need for a surrogate key for fct tables, we typically only do this for dims, except in rare cases where other fct tables need a direct link to this fct

[oscarrezab]

Implemented fixes suggested in comments.

TODO

• Continue to think about the renaming and repurposing of the fct_candidate_assessment table. One option is to let it generally be a fct_performance_evaluation_rating table that allows for evaluations for any type of person.
  • This would require more conversation of the role of person in EPDM and thus in the warehouse.