Add dim_candidate.sql and dim_candidate.yml from feature/epdm_models … #195
Conversation
| k_candidate, | ||
| k_person, | ||
| tenant_code, | ||
| api_year, |
There was a problem hiding this comment.
we tend not to include api_year in wh models, bc unlike school_year, it doesn't really have analytical meaning. Sometimes, however, we rename it to school_year in stg, when school_year isn't available in the source ed-fi endpoint.
maybe that's something we should add to the stg model for candidates.. like we do in stuEdOrg
There was a problem hiding this comment.
I think this comes down to a decision: do we want to treat candidates like students, in that there's one record per candidate + year, or like staffs, in that there's one record per candidate. Maybe this is worth asking at dev meeting
| Defines an educator candidate. | ||
|
|
||
| ##### Primary Key: | ||
| `k_candidate` - There is one record per candidate |
There was a problem hiding this comment.
technically candidate and year, right? assuming ODSes are single-year
There was a problem hiding this comment.
we should probably apply some of the same transformations that we apply to staff & students, to candidates. for example:
- race/ethnicity transformation
- other names
- immutable demos?
- maybe leave out contact info like addresses, emails? are those needed for Crocus' app, though?
Description & motivation
dim_candidate model for EPDM data. Created as part of summer intern final project and split from original PR that included multiple models. Jira task: STAD-213
PR Merge Priority:
New files created:
dim_candidate.sql: dimension table to describe an educator candidatedim_candidate.yml: YAML to describe table aboveTests and QC done:
edu_wh PR Review Checklist:
Make sure the following have been completed before approving this PR:
## New Featuresfor features, etc.