Feature/new structure dbt

[sakshii130923]

Added new models in models_v2 folder

[siddhant3030]

why text fields are here in intermediate? staging keeps them as integers. This creates fragile joins downstream -- look at dim_crm_partner.sql. Keep IDs as their natural type (integer) throughout, or at least be consistent.

[siddhant3030]

same thing here fix this. should be in staging as integer or numeric

[siddhant3030]

Same — mou_id::text, partner_id::text.

[siddhant3030]

why in staging name is different from here?

stg_bubble__children but here its int_bubble__child.sql? let's keep it consistent?

[sakshii130923]

Naming convention changed

[siddhant3030]

Missing surrogate key. Add {{ dbt_utils.generate_surrogate_key(['child_id']) }} as child_sk as the first column. Surrogate keys are best practice for dimensional modeling — they decouple your warehouse from source system IDs. (Applies to ALL 10 dimension files.)

[sakshii130923]

Added surrogate keys in int layer

[siddhant3030]

If a POC always belongs to exactly one partner (1:1 relationship, never changes) — then keeping partner_id in dim_poc is actually fine. Just drop bridge_poc_partner since it's redundant.

If a POC can belong to multiple partners (or the assignment changes over time) — then remove partner_id from dim_poc and rely on bridge_poc_partner for the relationship. The dimension becomes a pure description of the person

[siddhant3030]

this is a 1:1 copy of int_bubble__school_volunteer with no added value. A fact table should: (1) have explicit FK references to dimension surrogate keys, (2) include measures (e.g. days_active, assignment_count), (3) filter out soft-deleted rows if appropriate.

what if we do something like this?

-- fct_school_volunteer: One row per volunteer-school assignment
-- Grain: one record per volunteer assigned to one school in one academic year

select
    school_volunteer_id,

    -- dimension FKs
    school_id,
    volunteer_id,
    academic_year,

    -- assignment dates
    created_date as assigned_date,
    modified_date,

    -- measures
    case
        when is_removed = false
        then current_date - created_date::date
        else modified_date::date - created_date::date
    end as days_assigned,

    not is_removed as is_active

from {{ ref('int_bubble__school_volunteer') }}
where is_removed = false

example
days_assigned gives you something to actually aggregate on. Right now there's nothing to SUM() or AVG() in this table. You can answer "what's the average volunteer tenure per school?" directly from the fact

[siddhant3030]

Same issue — 1:1 copy of int_crm__meetings. Consider adding: meeting duration, days until follow-up, a has_follow_up boolean derived metric, and FK references to dim_crm_partner, dim_poc

[siddhant3030]

Same — direct pass-through. Add: days_to_conversion, is_converted boolean, FK to dim_crm_partner.

[siddhant3030]

Missing a volunteer_id FK reference to a dim_volunteer dimension (which doesn't exist yet). The fact references volunteer_id but there's no dimension to join it to.