Skip to content

Commit 3f3d7a1

Browse files
committed
update documentation of model according ecore genmodel documentation anotation
Signed-off-by: Stefan Bischof <[email protected]>
1 parent df76a2e commit 3f3d7a1

File tree

114 files changed

+1261
-867
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

114 files changed

+1261
-867
lines changed

docs/cubeserver/model/class-AbstractElement.md

Lines changed: 7 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -5,7 +5,7 @@ group: Class
55

66
# AbstractElement<a name="class-abstractelement"></a>
77

8-
8+
The fundamental base class for all named elements in the ROLAP mapping model. This abstract class provides the essential identity, naming, and extensibility infrastructure that all OLAP schema components require. It establishes the core patterns for element identification, user-friendly naming, descriptive content, custom annotations, and documentation integration. Every major schema component (Catalog, Cube, Dimension, Hierarchy, Level, Measure, etc.) inherits from this class, ensuring consistent identity management and extensibility across the entire OLAP framework.
99
## Extends
1010
- DocumentedElement [🔗](./class-DocumentedElement)
1111
## Attributes
@@ -15,7 +15,7 @@ group: Class
1515
<tr>
1616
<th>Name</th>
1717
<th>Id</th>
18-
<th>Typ</th>
18+
<th>Type</th>
1919
<th>Lower</th>
2020
<th>Upper</th>
2121
</tr>
@@ -29,7 +29,7 @@ group: Class
2929
<td>1</td>
3030
</tr>
3131
<tr>
32-
<td colspan="5"><em> here you will see the description.</em></td>
32+
<td colspan="5"><em>Unique identifier for this element within the scope of its containing model. This ID serves as the primary key for object references, cross-references between elements, and internal system operations. The ID must be unique and eigther should follow consistent naming conventions (e.g., '_cube_sales', '_dim_product'),or may uses UUIDs. This identifier is used by the OLAP engine for object lookup, caching keys, and maintaining referential integrity during schema transformations.</em></td>
3333
</tr>
3434
<tr>
3535
<td><strong>description</strong></td>
@@ -39,7 +39,7 @@ group: Class
3939
<td>1</td>
4040
</tr>
4141
<tr>
42-
<td colspan="5"><em> here you will see the description.</em></td>
42+
<td colspan="5"><em>Human-readable description that provides additional context and explanation for this element. This field supports detailed explanations of the element's purpose, business meaning, usage guidelines, or implementation notes. Unlike formal documentation, this is typically a single paragraph or brief text that appears in development tools, schema browsers, or administrative interfaces to help users understand the element's role and usage.</em></td>
4343
</tr>
4444
<tr>
4545
<td><strong>name</strong></td>
@@ -49,7 +49,7 @@ group: Class
4949
<td>1</td>
5050
</tr>
5151
<tr>
52-
<td colspan="5"><em> here you will see the description.</em></td>
52+
<td colspan="5"><em>Display name for this element that appears in user interfaces, reports, MDX queries, and XMLA metadata. This should be a user-friendly name that business users will recognize and understand. Unlike the ID, this name doesn't need to be unique across the entire schema and can contain spaces, special characters, and international characters. For example, a dimension might have id='_dim_product' and name='Product Catalog'.</em></td>
5353
</tr>
5454
</tbody>
5555
</table>
@@ -60,7 +60,7 @@ group: Class
6060
<thead>
6161
<tr>
6262
<th>Name</th>
63-
<th>Typ</th>
63+
<th>Type</th>
6464
<th>Lower</th>
6565
<th>Upper</th>
6666
<th>Containment</th>
@@ -75,7 +75,7 @@ group: Class
7575
<td>true</td>
7676
</tr>
7777
<tr>
78-
<td colspan="5"><em> here you will see the description.</em></td>
78+
<td colspan="5"><em>Collection of custom annotations that provide extensibility and additional metadata for this element. Annotations allow for vendor-specific extensions, optimization hints, caching directives, security policies, display formatting rules, or integration parameters without modifying the core model. This enables customization for specific OLAP engines, reporting tools, or business requirements while maintaining schema portability.</em></td>
7979
</tr>
8080
</tbody>
8181
</table>

docs/cubeserver/model/class-AccessCatalogGrant.md

Lines changed: 6 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -5,7 +5,7 @@ group: Class
55

66
# AccessCatalogGrant<a name="class-accesscataloggrant"></a>
77

8-
8+
Represents a catalog-level security grant that defines the foundational access permissions for an OLAP catalog and serves as the root of the hierarchical access control evaluation process. AccessCatalogGrant establishes the primary security boundary that determines whether a role can access any resources within a specific catalog, and when custom access is specified, it provides the container for more granular cube-level and database schema-level grants that define precisely which catalog resources are accessible.
99
## Extends
1010

1111
## Attributes
@@ -15,7 +15,7 @@ group: Class
1515
<tr>
1616
<th>Name</th>
1717
<th>Id</th>
18-
<th>Typ</th>
18+
<th>Type</th>
1919
<th>Lower</th>
2020
<th>Upper</th>
2121
</tr>
@@ -29,7 +29,7 @@ group: Class
2929
<td>1</td>
3030
</tr>
3131
<tr>
32-
<td colspan="5"><em> here you will see the description.</em></td>
32+
<td colspan="5"><em>Enumerated value that specifies the level of access this role has to the catalog and all its contained resources, serving as the primary access control decision point for catalog-level operations. The access level determines the overall scope of permissions and influences how sub-grants are evaluated and applied. When set to ALL, the role receives complete unrestricted access to the entire catalog including all cubes, dimensions, hierarchies, members, and database objects, effectively granting administrative privileges for the catalog scope. When set to NONE, the role is completely denied access to the catalog and all its contents, preventing any interaction with catalog resources regardless of any sub-grants that might be defined. When set to ALL_DIMENSIONS, the role receives access to shared dimensions and their metadata but is denied access to cubes and fact data, enabling metadata browsing and dimension exploration scenarios without exposing sensitive measure data. When set to CUSTOM, the role's access is determined by the explicit cubeGrants and databaseSchemaGrants collections, enabling fine-grained security policies where specific permissions are granted only for explicitly authorized resources. The CUSTOM setting is most commonly used in enterprise scenarios where complex security requirements necessitate selective access to different parts of the catalog based on business roles, organizational hierarchies, regulatory requirements, or multi-tenant isolation needs.</em></td>
3333
</tr>
3434
</tbody>
3535
</table>
@@ -40,7 +40,7 @@ group: Class
4040
<thead>
4141
<tr>
4242
<th>Name</th>
43-
<th>Typ</th>
43+
<th>Type</th>
4444
<th>Lower</th>
4545
<th>Upper</th>
4646
<th>Containment</th>
@@ -55,7 +55,7 @@ group: Class
5555
<td>true</td>
5656
</tr>
5757
<tr>
58-
<td colspan="5"><em> here you will see the description.</em></td>
58+
<td colspan="5"><em>Collection of cube-level access grants that define specific permissions for individual cubes within the catalog when the catalogAccess is set to CUSTOM, enabling fine-grained control over which analytical resources are accessible to the role. Each AccessCubeGrant specifies whether the role has complete access to a cube (ALL), no access to the cube (NONE), or selective access that requires additional dimension and hierarchy grants (CUSTOM). Cube grants are essential for implementing business-oriented security models where different user groups need access to different analytical domains such as sales cubes for sales teams, financial cubes for finance departments, and operational cubes for operations managers. This granular approach supports complex enterprise scenarios including multi-departmental organizations where users should only see cubes relevant to their business function, regulatory compliance requirements where certain cubes contain sensitive data that must be restricted to authorized personnel, performance optimization where access restrictions reduce the scope of metadata loading and query processing, and multi-tenant deployments where different customer organizations require access to different analytical content. The cube grant level is particularly important because cubes represent complete analytical contexts with their associated dimensions, measures, and calculated members, making cube-level security an effective way to implement business-domain-based access control that aligns with organizational structures and analytical usage patterns.</em></td>
5959
</tr>
6060
<tr>
6161
<td><strong>databaseSchemaGrants</strong></td>
@@ -65,7 +65,7 @@ group: Class
6565
<td>true</td>
6666
</tr>
6767
<tr>
68-
<td colspan="5"><em> here you will see the description.</em></td>
68+
<td colspan="5"><em>Collection of database schema-level access grants that define permissions for accessing the underlying database structures that support the OLAP catalog, extending security control beyond the logical OLAP model to the physical data layer. Each AccessDatabaseSchemaGrant specifies access permissions for database schemas, tables, and columns, enabling comprehensive data governance that covers both analytical access through OLAP operations and potential direct data access through SQL queries or data integration processes. Database schema grants are crucial for implementing defense-in-depth security strategies where access control is enforced at multiple layers of the data architecture, for regulatory compliance scenarios where data access must be auditable and restrictable at the database level regardless of the access method, for supporting hybrid analytical environments where users might access data through both OLAP tools and direct SQL interfaces, and for enabling administrative scenarios where technical users need access to underlying database structures for maintenance, optimization, or troubleshooting purposes. The database-level security integration ensures that OLAP security policies are consistent with broader enterprise data governance frameworks and provides additional protection against unauthorized data access that might bypass the OLAP layer entirely.</em></td>
6969
</tr>
7070
</tbody>
7171
</table>

docs/cubeserver/model/class-AccessColumnGrant.md

Lines changed: 5 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -5,7 +5,7 @@ group: Class
55

66
# AccessColumnGrant<a name="class-accesscolumngrant"></a>
77

8-
8+
Provides the most granular level of database security control by defining access permissions for individual database columns, enabling extremely precise data governance policies that can restrict access to specific data elements based on sensitivity, regulatory requirements, privacy concerns, or business confidentiality needs.
99
## Extends
1010

1111
## Attributes
@@ -15,7 +15,7 @@ group: Class
1515
<tr>
1616
<th>Name</th>
1717
<th>Id</th>
18-
<th>Typ</th>
18+
<th>Type</th>
1919
<th>Lower</th>
2020
<th>Upper</th>
2121
</tr>
@@ -29,7 +29,7 @@ group: Class
2929
<td>1</td>
3030
</tr>
3131
<tr>
32-
<td colspan="5"><em> here you will see the description.</em></td>
32+
<td colspan="5"><em>Specifies the access level for the column using ColumnAccess enumeration values, providing the finest-grained control over data access at the individual column level.</em></td>
3333
</tr>
3434
</tbody>
3535
</table>
@@ -40,7 +40,7 @@ group: Class
4040
<thead>
4141
<tr>
4242
<th>Name</th>
43-
<th>Typ</th>
43+
<th>Type</th>
4444
<th>Lower</th>
4545
<th>Upper</th>
4646
<th>Containment</th>
@@ -55,7 +55,7 @@ group: Class
5555
<td>false</td>
5656
</tr>
5757
<tr>
58-
<td colspan="5"><em> here you will see the description.</em></td>
58+
<td colspan="5"><em>References the specific column to which this access grant applies, establishing the security boundary at the individual column level.</em></td>
5959
</tr>
6060
</tbody>
6161
</table>

docs/cubeserver/model/class-AccessCubeGrant.md

Lines changed: 7 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -5,7 +5,7 @@ group: Class
55

66
# AccessCubeGrant<a name="class-accesscubegrant"></a>
77

8-
8+
Defines cube-level security permissions that control access to a specific OLAP cube and provide the foundation for more granular dimension, hierarchy, and member-level access controls within that analytical context. AccessCubeGrant operates as the primary business-domain security boundary, since cubes typically represent complete analytical subjects such as Sales Analysis, Financial Reporting, or Operations Management that align with organizational responsibilities and business processes.
99
## Extends
1010

1111
## Attributes
@@ -15,7 +15,7 @@ group: Class
1515
<tr>
1616
<th>Name</th>
1717
<th>Id</th>
18-
<th>Typ</th>
18+
<th>Type</th>
1919
<th>Lower</th>
2020
<th>Upper</th>
2121
</tr>
@@ -29,7 +29,7 @@ group: Class
2929
<td>1</td>
3030
</tr>
3131
<tr>
32-
<td colspan="5"><em> here you will see the description.</em></td>
32+
<td colspan="5"><em>Specifies the access level for the cube using the CubeAccess enumeration values (all, none, custom), determining whether role members can view cube data and structure.</em></td>
3333
</tr>
3434
</tbody>
3535
</table>
@@ -40,7 +40,7 @@ group: Class
4040
<thead>
4141
<tr>
4242
<th>Name</th>
43-
<th>Typ</th>
43+
<th>Type</th>
4444
<th>Lower</th>
4545
<th>Upper</th>
4646
<th>Containment</th>
@@ -55,7 +55,7 @@ group: Class
5555
<td>true</td>
5656
</tr>
5757
<tr>
58-
<td colspan="5"><em> here you will see the description.</em></td>
58+
<td colspan="5"><em>Collection of dimension-level access grants that provide fine-grained security control over specific dimensions within the cube's multidimensional space.</em></td>
5959
</tr>
6060
<tr>
6161
<td><strong>hierarchyGrants</strong></td>
@@ -65,7 +65,7 @@ group: Class
6565
<td>true</td>
6666
</tr>
6767
<tr>
68-
<td colspan="5"><em> here you will see the description.</em></td>
68+
<td colspan="5"><em>Collection of hierarchy-level access grants that define granular security permissions for specific hierarchies within the cube's dimensional structure.</em></td>
6969
</tr>
7070
<tr>
7171
<td><strong>cube</strong></td>
@@ -75,7 +75,7 @@ group: Class
7575
<td>false</td>
7676
</tr>
7777
<tr>
78-
<td colspan="5"><em> here you will see the description.</em></td>
78+
<td colspan="5"><em>References the specific cube instance to which this access grant applies, establishing the security boundary for the targeted analytical domain.</em></td>
7979
</tr>
8080
</tbody>
8181
</table>

docs/cubeserver/model/class-AccessDatabaseSchemaGrant.md

Lines changed: 6 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -5,7 +5,7 @@ group: Class
55

66
# AccessDatabaseSchemaGrant<a name="class-accessdatabaseschemagrant"></a>
77

8-
8+
Extends the OLAP security model to the database level by controlling access to database schemas, tables, and columns that underlie the OLAP analytical structures, providing comprehensive data governance that enforces security policies regardless of how data is accessed.
99
## Extends
1010

1111
## Attributes
@@ -15,7 +15,7 @@ group: Class
1515
<tr>
1616
<th>Name</th>
1717
<th>Id</th>
18-
<th>Typ</th>
18+
<th>Type</th>
1919
<th>Lower</th>
2020
<th>Upper</th>
2121
</tr>
@@ -29,7 +29,7 @@ group: Class
2929
<td>1</td>
3030
</tr>
3131
<tr>
32-
<td colspan="5"><em> here you will see the description.</em></td>
32+
<td colspan="5"><em>Defines the access level for the database schema using DatabaseSchemaAccess enumeration values, controlling whether role members can interact with schema structures.</em></td>
3333
</tr>
3434
</tbody>
3535
</table>
@@ -40,7 +40,7 @@ group: Class
4040
<thead>
4141
<tr>
4242
<th>Name</th>
43-
<th>Typ</th>
43+
<th>Type</th>
4444
<th>Lower</th>
4545
<th>Upper</th>
4646
<th>Containment</th>
@@ -55,7 +55,7 @@ group: Class
5555
<td>true</td>
5656
</tr>
5757
<tr>
58-
<td colspan="5"><em> here you will see the description.</em></td>
58+
<td colspan="5"><em>Collection of table-level access grants that provide granular security control over specific tables within the database schema.</em></td>
5959
</tr>
6060
<tr>
6161
<td><strong>databaseSchema</strong></td>
@@ -65,7 +65,7 @@ group: Class
6565
<td>false</td>
6666
</tr>
6767
<tr>
68-
<td colspan="5"><em> here you will see the description.</em></td>
68+
<td colspan="5"><em>References the specific database schema to which this access grant applies, establishing the security boundary at the database level.</em></td>
6969
</tr>
7070
</tbody>
7171
</table>

docs/cubeserver/model/class-AccessDimensionGrant.md

Lines changed: 5 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -5,7 +5,7 @@ group: Class
55

66
# AccessDimensionGrant<a name="class-accessdimensiongrant"></a>
77

8-
8+
Defines dimension-level security permissions that control access to specific dimensions within a cube, providing targeted control over dimensional navigation and member visibility.
99
## Extends
1010

1111
## Attributes
@@ -15,7 +15,7 @@ group: Class
1515
<tr>
1616
<th>Name</th>
1717
<th>Id</th>
18-
<th>Typ</th>
18+
<th>Type</th>
1919
<th>Lower</th>
2020
<th>Upper</th>
2121
</tr>
@@ -29,7 +29,7 @@ group: Class
2929
<td>1</td>
3030
</tr>
3131
<tr>
32-
<td colspan="5"><em> here you will see the description.</em></td>
32+
<td colspan="5"><em>Specifies the access level for the dimension using DimensionAccess enumeration values, controlling whether role members can view and navigate the dimension.</em></td>
3333
</tr>
3434
</tbody>
3535
</table>
@@ -40,7 +40,7 @@ group: Class
4040
<thead>
4141
<tr>
4242
<th>Name</th>
43-
<th>Typ</th>
43+
<th>Type</th>
4444
<th>Lower</th>
4545
<th>Upper</th>
4646
<th>Containment</th>
@@ -55,7 +55,7 @@ group: Class
5555
<td>false</td>
5656
</tr>
5757
<tr>
58-
<td colspan="5"><em> here you will see the description.</em></td>
58+
<td colspan="5"><em>References the specific dimension to which this access grant applies, establishing the security boundary at the dimension level.</em></td>
5959
</tr>
6060
</tbody>
6161
</table>

0 commit comments

Comments
 (0)