Bug: Some Airtable configurations have edge cases that make analysis difficult for analysis team

[vevetron]

Where did the bug occur?
Select from the below, and be sure to affix the appropriate label to this issue (e.g. dataset, jupyterhub, metabase, analysis.calitp.org)

• Data (the warehouse)
• JupyterHub
• Metabase
• analysis.calitp.org
• Other (add detail)

Describe the bug
I'm trying to figure out a simple way to design Reports v2.

In conversation with @tiffanychu90 and @edasmalchi , they suggest there are many edge cases when analyzing our data when figuring out analysis patterns. They suggested Analysis_name is not sufficient to handle everything. But there are problems with how TDQ has organized things in airtable.

It would be helpful if the actual consumers of the data can tell us what some of those edge cases are to see if there are opportunities to modify our airtable SOPs.

If its not possible, that sucks too, but I'd love to know what those edge cases are.

Expected behavior
Making dashboards is easier!!

Additional context

[tiffanychu90]

This would be a further development of cal-itp/data-infra#4161. @vevetron / @edasmalchi were decision makers around this idea, and have maintained Airtable entries, so would be best equipped to diagnosing the why and the how to address this. I'll defer to their judgment on how they choose to maintain this going forward / how this will be used broadly for all our data products.

Here's the context around where I saw potential edge cases:

• When adding this schedule + RT operator summary, a left join and full outer join gave me different number of rows (should there be rows appearing in an RT dataset that is not found in schedule)?
  fct_daily_schedule_rt_operator_summary.
• This bridge table from combines GTFS dataset name to analysis_name. This model updates every Thurs only, so changes in Airtable are not immediately seen, but should capture the "universe" of operators we care about.