Entities and attributes

[vitali-yanushchyk-valor]

Still not so clear - why do we need to define fields like full_name, given_name, birth_date, etc. separately in the Country Workspace models if we only need to validate and forward data that fully matches the programme rules to HOPE?

Do these entity relations correlate with the purely Country Workspace scope?

erDiagram
    Individual }o--|| Household : ""
    Individual {
        string relationship "nullable"
        JSON programme_fields "nullable"
        JSON extra_fields "nullable"
        datetime created_at
        int household_id "nullable"
    }
    Household }o--|| CountryOffice : ""
    Household {
        JSON programme_fields "nullable"
        JSON extra_fields "nullable"
        datetime created_at
        int country_office_id
    }
    IndividualHistory }o--|| Individual : ""
    IndividualHistory {
        string field_name
        string old_value
        string new_value
        datetime created_at
        int individual_id
    }
    HouseholdHistory }o--|| Household : ""
    HouseholdHistory {
        string field_name
        string old_value
        string new_value
        datetime created_at
        int household_id
    }
    Document }o--|| Individual : ""
    Document {
        string document_number "nullable"
        Image photo "nullable"
        JSON programme_fields "nullable"
        JSON extra_fields "nullable"
        datetime created_at
        int individual_id
    }

Loading

• Individual, Household, Document have:
  • relation fields like FK
  • programme_fields containing data that follows programme rules, validated and populated using datachecker
  • extra_fields holding any other data not corresponding to programme rules but present in the xls file
  • created_at indicating the datetime of creation
• Individual has relationship field, which is nullable, and can be used to store the relationship between individuals and households as string from the list of predefined values.
• Document has document_number and photo fields, maybe it`s better to store it as separate fields.
• IndividualHistory, HouseholdHistory can be created to store the history of changes in the main tables, containing:
  • information about the changed field, which can be stored in three separate string fields or in a single JSON field
  • created_at indicating the datetime of creation

[domdinicola]

@vitali-yanushchyk-valor what about a DocumentHistory model?