|Designing GemFire XD Databases|
The GemFire XD architecture encourages you to denormalize "dimension" tables into fact tables when possible, and then replicate remaining dimension tables to all datastores in the distributed system.
Most databases follow the star schema design pattern where large "fact" tables store key information about the events in a system or a business process. For example, a fact table would store rows for events like product sales or bank transactions. Each fact table generally has foreign key relationships to multiple "dimension" tables, which describe further aspects of each row in the fact table. In the previous examples, dimension tables would contain information about the products involved in each sale, or the accounts associated with each transaction, and so forth.
When designing a database schema for GemFire XD, the main goal with a typical star schema database is to partition the entities in fact tables (see Identify Entity Groups and Partitioning Keys). Slow-changing dimension tables should then be replicated on each data store that hosts a partitioned fact table. In this way, a join between the fact table and any number of its dimension tables can be executed concurrently on each partition, without requiring multiple network hops to other members in the distributed system.
See Replicating Tables for more information about how to replicate tables in GemFire XD.