# Chasm and Fan Traps

> A chasm trap occurs when two many-to-one joins converge on a single table, and the query includes measures from both leaf tables. A fan trap occurs when two many-to-one joins follow one another in primary-detail form (OrderDetails), and the query includes a measure from both the leaf table (OrderDetails) and its immediate primary (Orders).

*Source: https://docs.sisense.com/main/SisenseLinux/chasm-and-fan-traps.htm*

---

Last updated: June 21, 2026

|  |  |
| --- | --- |
| [Tier](https://www.sisense.com/pricing/#pricing) | [Deployment](https://docs.sisense.com/main/SisenseLinux/introduction-to-sisense-cloud-managed-services.md#ComparisonofManagedCloudandSelfHosted) |
| Launch     Grow    Enterprise | Cloud     On-Prem |

**Note:**

The images on this page were taken in the desktop version of Sisense. However, the same principles described on
this page also apply to the web-based ElastiCube Manager.

  

Chasm and fan traps should be avoided when building your ElastiCube schemas.

## Chasm Traps

A chasm trap occurs when two **many-to-one** joins converge on a single table, and the query
includes measures from both leaf tables. As a result multiple rows are returned from the tables when processing the
query.

![Chasm trap](https://docs.sisense.com/main/Resources/Images/chasm-trap.png)

If you were to calculate both measures (Qty and Value) simultaneously, like in the following example, the values for
Customers will be multiplied due to the inner join between the leaf tables, and the results may be incorrect:

![8 6chasm2thumb](https://docs.sisense.com/main/Resources/Images/8-6chasm2thumb0300_697x357.png)

## Fan Traps

A fan trap occurs when two **many-to-one** joins follow one another in primary-detail form
(OrderDetails), and the query includes a measure from both the leaf table (OrderDetails) and its immediate primary
(Orders).

![Fan trap](https://docs.sisense.com/main/Resources/Images/fan-trap.png)

If you try to aggregate both measures simultaneously (using the query below), you will probably get incorrect
results:

![8 6chasm4thumb](https://docs.sisense.com/main/Resources/Images/8-6chasm4thumb0300_833x375.png)

The **Qty** measure, corresponding to the leaf measure table (OrderDetails) is calculated
correctly, but the **Value** measure, corresponding to the measure held in its primary (Orders),
is not. This is because we get the **Value** of every OrderID, which may inflate the expected
results.

The web application translation module separates the calculations, and unions the results by generating a query for
each of the measures' paths (path in terms of tables to go by). Then the web application translation module will group
all the measures with the same tables' paths into one query and union it with all the other **same path
measures** with different paths.

The described **Chasm Trap** can be prevented like this:

![8 6chasm5thumb](https://docs.sisense.com/main/Resources/Images/8-6chasm5thumb0300_816x412.png)

And the **Fan Trap** will be prevented this way:

![8 6chasm6thumb](https://docs.sisense.com/main/Resources/Images/8-6chasm6thumb0300_819x445.png)