Hey @Akshatkumar69, welcome to the community.

You're not alone on this one, it is common with folks coming from Power BI.

The key thing to understand is that AI/BI charts do expect a single data source, but that source can be a metric view that already joins your tables together. You don't need to pick just one table.

For your Sales + Product example, this is a classic fact-to-dimension pattern, and metric views handle it natively through the joins block in the YAML:

version: 0.1
source: my_catalog.my_schema.sales

joins:
  - name: product
    source: my_catalog.my_schema.product
    on: product.product_id = source.product_id

dimensions:
  - name: State
    expr: state
  - name: Maker
    expr: product.maker

measures:
  - name: Total Sales
    expr: SUM(sales_amount)

Then in AI/BI, you point your chart at this single metric view. "Sales by State" and "Sales by Maker" both work from the same source because the join is already defined in the semantic layer.

One thing to be aware of. Metric view joins are designed for many-to-one relationships (fact to dimension). If you're joining two fact tables or dealing with a many-to-many relationship, the metric view join won't give you correct results. In those cases, create a pre-joined SQL view in Unity Catalog and use that as your metric view source instead.

The mental model shift from Power BI is this: instead of the tool resolving relationships at query time, you define them upfront in your metric view YAML. Once that's in place, the single-source constraint stops being a limitation.

Cheers, Lou