Skip to content

Commit 73320fb

Browse files
committed
fix overloaded code
is exicent, was removed befor Signed-off-by: Stefan Bischof <[email protected]>
1 parent f6d48f8 commit 73320fb

19 files changed

+53
-53
lines changed

docs/cubeserver/model/class-AggregationExclude.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -29,7 +29,7 @@ Defines exclusion rules that prevent specific tables from being used as aggregat
2929
<td>1</td>
3030
</tr>
3131
<tr>
32-
<td colspan="5"><em>Boolean flag that controls whether table name matching for this exclusion rule should be case-sensitive or case-insensitive. When set to true, the exclusion matching will ignore case differences, making exclusion rules more robust in environments with inconsistent case usage in table names or when working with databases that have varying case sensitivity behaviors. Case-insensitive matching is particularly useful in heterogeneous environments where table names might be created with different case conventions by various ETL tools, database administrators, or automated processes. This setting should align with the database system's case sensitivity behavior and the organization's naming conventions to ensure exclusion rules work reliably across all deployment scenarios.</em></td>
32+
<td colspan="5"><em>Boolean flag that controls whether table name matching for this exclusion rule should be case-sensitive or case-insensitive. When set to true, the exclusion matching will ignore case differences, making exclusion rules more robust in environments with inconsistent case usage in table names or when working with databases that have varying case sensitivity behaviors.</em></td>
3333
</tr>
3434
<tr>
3535
<td><strong>name</strong></td>
@@ -39,7 +39,7 @@ Defines exclusion rules that prevent specific tables from being used as aggregat
3939
<td>1</td>
4040
</tr>
4141
<tr>
42-
<td colspan="5"><em>Exact table name that should be excluded from aggregation table consideration. When specified, this provides precise exclusion control for specific known tables that should never be used for aggregation, regardless of whether they match aggregation patterns or appear to contain suitable aggregation data. Name-based exclusion is ideal for handling specific problematic tables, tables with known data quality issues, or tables that are reserved for other purposes but might otherwise be mistaken for aggregation tables. This exact matching approach complements pattern-based exclusion by providing surgical control over individual tables while maintaining the broader pattern-based approach for categories of tables.</em></td>
42+
<td colspan="5"><em>Exact table name that should be excluded from aggregation table consideration. When specified, this provides precise exclusion control for specific known tables that should never be used for aggregation, regardless of whether they match aggregation patterns or appear to contain suitable aggregation data.</em></td>
4343
</tr>
4444
<tr>
4545
<td><strong>pattern</strong></td>

docs/cubeserver/model/class-AggregationTable.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -95,7 +95,7 @@ Abstract base class for pre-computed aggregation tables that dramatically improv
9595
<td>true</td>
9696
</tr>
9797
<tr>
98-
<td colspan="5"><em>Collection of measure mappings that define how pre-aggregated measure values in the aggregation table correspond to measures in the fact table and cube definition. Each AggregationMeasure specifies the measure name, the aggregation table column containing the pre-computed values, and the rollup type (SUM, AVG, COUNT, etc.) that determines how values can be further aggregated when rolling up to higher levels. This mapping is critical for enabling the OLAP engine to substitute aggregation table data for fact table scans, with measures like Sales Amount typically using SUM rollup, while distinct count measures require special handling to maintain accuracy across aggregation levels. The system supports complex measure scenarios including calculated measures, currency conversions, and weighted averages through appropriate rollup type specifications.</em></td>
98+
<td colspan="5"><em>Collection of measure mappings that define how pre-aggregated measure values in the aggregation table correspond to measures in the fact table and cube definition. Each AggregationMeasure specifies the measure name, the aggregation table column containing the pre-computed values, and the rollup type (SUM, AVG, COUNT, etc.) that determines how values can be further aggregated when rolling up to higher levels.</em></td>
9999
</tr>
100100
<tr>
101101
<td><strong>aggregationLevels</strong></td>
@@ -105,7 +105,7 @@ Abstract base class for pre-computed aggregation tables that dramatically improv
105105
<td>true</td>
106106
</tr>
107107
<tr>
108-
<td colspan="5"><em>Collection of dimension level mappings that specify which dimensional granularities are represented in this aggregation table and how they map to aggregation table columns. Each AggregationLevel defines the connection between a dimension level (such as Product Category, Time Month, or Geography State) and the corresponding column in the aggregation table that contains the level's key values. These mappings enable the OLAP engine's aggregation matching algorithm to determine whether a given aggregation table can satisfy a query's dimensional requirements, support proper constraint propagation, and enable rollup operations when the aggregation contains more detailed levels than required by the query. Level mappings also support collapsed hierarchies where intermediate levels are skipped, caption columns for display purposes, and level properties for additional dimensional attributes stored in the aggregation table.</em></td>
108+
<td colspan="5"><em>Collection of dimension level mappings that specify which dimensional granularities are represented in this aggregation table and how they map to aggregation table columns. Each AggregationLevel defines the connection between a dimension level (such as Product Category, Time Month, or Geography State) and the corresponding column in the aggregation table that contains the level's key values.</em></td>
109109
</tr>
110110
<tr>
111111
<td><strong>aggregationMeasureFactCounts</strong></td>

docs/cubeserver/model/class-CalculatedMember.md

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -29,7 +29,7 @@ Represents sophisticated computed members that are dynamically calculated using
2929
<td>1</td>
3030
</tr>
3131
<tr>
32-
<td colspan="5"><em>MDX expression that defines the calculation logic for this computed member, encapsulating sophisticated business rules, mathematical formulations, and analytical computations that determine the member's value based on other measures, members, and dimensional context. The formula serves as the computational heart of the calculated member, enabling complex analytical scenarios including financial ratio calculations that combine multiple measures with mathematical operations, time-based calculations that implement period-over-period comparisons and trend analysis, conditional logic that applies different calculation rules based on dimensional attributes or member properties, and cross-dimensional calculations that aggregate or transform data across multiple analytical perspectives. This formula specification supports the full range of MDX capabilities including set operations for member selection and filtering, statistical functions for advanced analytical computations, hierarchical navigation for parent-child calculations and drill-up operations, and temporal functions for time-based analysis and forecasting scenarios. The formula enables sophisticated business intelligence applications where calculated members serve as reusable analytical building blocks that encapsulate complex business logic, ensure consistent calculation methodologies across analytical applications, and provide performance optimization through intelligent caching and query optimization strategies that enable real-time analytical computations across large data volumes and complex multidimensional structures.</em></td>
32+
<td colspan="5"><em>MDX expression that defines the calculation logic for this computed member, encapsulating sophisticated business rules, mathematical formulations, and analytical computations that determine the member's value based on other measures, members, and dimensional context. The formula serves as the computational heart of the calculated member, enabling complex analytical scenarios including financial ratio calculations that combine multiple measures with mathematical operations, time-based calculations that implement period-over-period comparisons and trend analysis, conditional logic that applies different calculation rules based on dimensional attributes or member properties, and cross-dimensional calculations that aggregate or transform data across multiple analytical perspectives.</em></td>
3333
</tr>
3434
<tr>
3535
<td><strong>parent</strong></td>
@@ -39,7 +39,7 @@ Represents sophisticated computed members that are dynamically calculated using
3939
<td>1</td>
4040
</tr>
4141
<tr>
42-
<td colspan="5"><em>MDX expression that identifies the parent member within the dimensional hierarchy where this calculated member should be positioned, establishing the hierarchical context and navigational placement that determines how the calculated member appears in dimensional browsers, OLAP client tools, and analytical applications. The parent specification enables sophisticated calculated member organization where computed members can be logically grouped with related dimensional concepts, positioned at appropriate hierarchical levels for intuitive user navigation, and integrated seamlessly with existing dimensional structures to provide cohesive analytical experiences. This hierarchical positioning is crucial for enterprise business intelligence deployments where calculated members must be organized in meaningful ways that reflect business logic and user mental models, supporting scenarios such as financial calculated members that are grouped under appropriate account hierarchies, performance indicators that are positioned within relevant organizational or product hierarchies, and analytical ratios that are placed alongside related operational or strategic metrics. The parent specification also enables sophisticated calculated member inheritance and scoping behaviors where calculated members can access parent-level context, participate in hierarchical aggregation patterns, and maintain proper analytical relationships with both stored and computed members throughout the dimensional structure while ensuring optimal query performance and user experience consistency across complex multidimensional analytical applications.</em></td>
42+
<td colspan="5"><em>MDX expression that identifies the parent member within the dimensional hierarchy where this calculated member should be positioned, establishing the hierarchical context and navigational placement that determines how the calculated member appears in dimensional browsers, OLAP client tools, and analytical applications. The parent specification enables sophisticated calculated member organization where computed members can be logically grouped with related dimensional concepts, positioned at appropriate hierarchical levels for intuitive user navigation, and integrated seamlessly with existing dimensional structures to provide cohesive analytical experiences.</em></td>
4343
</tr>
4444
</tbody>
4545
</table>
@@ -65,7 +65,7 @@ Represents sophisticated computed members that are dynamically calculated using
6565
<td>false</td>
6666
</tr>
6767
<tr>
68-
<td colspan="5"><em>Reference to the Hierarchy within which this calculated member should be positioned, establishing the dimensional context that determines the member's analytical scope, navigational placement, and integration with existing hierarchical structures. The hierarchy reference defines the analytical domain where the calculated member will be available for selection, filtering, and navigation operations, ensuring that computed members integrate seamlessly with dimensional browsing, member selection, and hierarchical drill-down capabilities provided by OLAP client applications and business intelligence tools. This hierarchical association is essential for sophisticated analytical modeling where calculated members must participate in dimensional analysis patterns, support hierarchical aggregation behaviors, and maintain proper analytical relationships with stored members throughout the dimensional structure. The hierarchy reference enables complex analytical scenarios including cross-hierarchical calculated members that can reference members from multiple hierarchies, hierarchical calculated member families where related computed members are organized within specific dimensional contexts, and dynamic calculated member placement where computed members can be positioned at different hierarchical levels based on analytical requirements and business logic. Enterprise implementations leverage the hierarchy reference for advanced analytical architectures including calculated member security integration where access controls are applied at the hierarchical level, calculated member caching strategies that optimize performance based on hierarchical usage patterns, and calculated member federation scenarios where computed members are distributed across multiple hierarchical contexts while maintaining unified analytical behavior and consistent user experience across complex multidimensional business intelligence environments.</em></td>
68+
<td colspan="5"><em>Reference to the Hierarchy within which this calculated member should be positioned, establishing the dimensional context that determines the member's analytical scope, navigational placement, and integration with existing hierarchical structures. The hierarchy reference defines the analytical domain where the calculated member will be available for selection, filtering, and navigation operations, ensuring that computed members integrate seamlessly with dimensional browsing, member selection, and hierarchical drill-down capabilities provided by OLAP client applications and business intelligence tools.</em></td>
6969
</tr>
7070
<tr>
7171
<td><strong>physicalCube</strong></td>
@@ -75,7 +75,7 @@ Represents sophisticated computed members that are dynamically calculated using
7575
<td>false</td>
7676
</tr>
7777
<tr>
78-
<td colspan="5"><em>Required reference to the PhysicalCube that contains and manages this calculated member, establishing the analytical context and data scope within which the calculated member operates and ensuring proper integration with the cube's dimensional structure, measure definitions, and query processing capabilities. The physical cube reference defines the analytical environment where the calculated member can access fact data, reference other measures and members, and participate in multidimensional analysis operations including slicing, dicing, drilling, and pivoting across the cube's dimensional space. This containment relationship is fundamental to the calculated member's functionality and performance, providing access to the cube's optimization strategies, caching mechanisms, and query processing infrastructure that enable efficient evaluation of complex calculated member expressions across large data volumes and sophisticated analytical scenarios. The physical cube reference supports advanced analytical architectures where calculated members can leverage cube-specific aggregation tables, dimensional hierarchies, and security contexts to provide optimal performance and appropriate access control while maintaining analytical consistency and business logic integrity. Enterprise implementations utilize the physical cube reference for sophisticated calculated member management including cube-level calculated member libraries that provide reusable analytical components, calculated member versioning strategies that enable analytical evolution while maintaining backward compatibility, and calculated member federation patterns where computed members can be shared across related cubes while maintaining proper analytical context and performance optimization characteristics specific to each cube's data structure and usage patterns.</em></td>
78+
<td colspan="5"><em>Required reference to the PhysicalCube that contains and manages this calculated member, establishing the analytical context and data scope within which the calculated member operates and ensuring proper integration with the cube's dimensional structure, measure definitions, and query processing capabilities. The physical cube reference defines the analytical environment where the calculated member can access fact data, reference other measures and members, and participate in multidimensional analysis operations including slicing, dicing, drilling, and pivoting across the cube's dimensional space.</em></td>
7979
</tr>
8080
</tbody>
8181
</table>

0 commit comments

Comments
 (0)