e data at various levels (daily, monthly, etc.) to reduce the amount of data processed during analysis. Partitioning: Though not yet implemented, we’re looking to options regarding partitioning the ssd_person and other larger tables based on frequently queried columns (e.g. into date ranges, 1yr, etc) to improve query efficiency. Specific to Power BI Star Schema: We know that Power BI can perform better/well with a star schema design. This involves having a central fact table linked to dimension tables, and we have achieved this around the ssd_person object. Avoid Complex Relationships: We have designed around the avoidance of many to many relations and in combination with the star schema, tried to maintain simple relationships to aid performance. Specific to Tableau Extracts: The use of Tableau created data extracts, optimised for speed is not required as the SSD is it’s own non-live extract. Hierarchies and Joins: We have actively avoided unnecessary joins; in some cases creating an un-normalised structure to better achieve this. Calculated Fields: Where stakeholders considered calculated fields relevant, the processing is already completed within the extract structure to avoid performance hits within such as Tableau. General Best Practices Data Cleaning: An underlying principal/aim of the SSD was to avoid less relevant data points from the core reporting CMS, and to a lesser extent to preprocess data. Within the initial SSD deployment, we have applied only limited cleaning (Date definitions, field size restrictions and restructuring (e.g into JSON objects). As the pilot group expands, we will be in a better position to assess the need for further underlying standardisation in data quality. Where data cleaning is considered of benefit to the wider community, it will b