# Partitioned Multi-Active Satellite

**URL:** <https://forum.data-community.org/t/partitioned-multi-active-satellite/2106>\
**Category:** Data Vault 2.0\
**Created:** [May 29, 2026, 9:15am UTC](https://forum.data-community.org/t/partitioned-multi-active-satellite/2106 "2026-05-29T09:15:46Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![patrickcuba](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.data-community.org/patrickcuba/32/19_2.png) [@patrickcuba](https://forum.data-community.org/u/patrickcuba)\
**Post date:** [May 29, 2026, 9:15am UTC](https://forum.data-community.org/t/partitioned-multi-active-satellite/2106/1 "2026-05-29T09:15:46Z")

</div>

What if you are in a modelling situation where you know you have dependent-child keys but you need to those partitions like a multi-active state of the business key? They are not composite keys (although business keys are rarely composite), but they do subcategorise the parent key.

I proposed this last year, [https://blog.devgenius.io/partitioned-multi-active-satellite-4860af2d8846?sk=b419afd03a8a1689b96ac16b29bcb9fc](https://blog.devgenius.io/partitioned-multi-active-satellite-4860af2d8846?sk=b419afd03a8a1689b96ac16b29bcb9fc)

Benefits

- Less tables to join on
- Hubs remain representative of the business key (as defined by business architecture) and only the business key
- Simplifies the dv models with less tables to join on, reduced number of link tables
- Suites NoSQL platforms where joins are not particularly performant

Would you find this pattern useful?