Aller au contenu
Saiku Cloud

Structure du schema

Un exemple complet

Voici un schema Mondrian-4 petit mais complet — un cube, une dimension, deux mesures. Saiku accepte les schemas en YAML (par défaut) ou en XML ; choisissez un format ci-dessous et chaque exemple du site change pour correspondre.

schema:
  name: "Sales Example"
  metamodel_version: "4.0"
physical_schema:
  tables:
  - name: "sales_fact"
    schema: "demo"
    key:
    - "sale_id"
  - name: "dim_customer"
    schema: "demo"
shared_dimensions:
  Customer:
    table: "dim_customer"
    key: "Customer"
    attributes:
    - name: "Customer"
      key:
      - "customer_id"
      name_column: "customer_name"
    - name: "Gender"
      key:
      - "gender"
      has_hierarchy: false
    hierarchies:
    - name: "Customers"
      levels:
      - "Gender"
      - "Customer"
cubes:
  Sales:
    dimensions:
    - source: "Customer"
    measure_groups:
    - name: "Sales"
      table: "sales_fact"
      measures:
      - name: "Unit Sales"
        column: "units"
        aggregator: "sum"
        format_string: "#,###"
      - name: "Revenue"
        column: "revenue"
        aggregator: "sum"
        format_string: "#,##0.00"
      dimension_links:
      - type: "foreign_key"
        dimension: "Customer"
        foreign_key_column: "customer_id"

Structure d’un schema

La structure globale d’un document XML de schema Mondrian-4 ressemble à ceci :

<Schema>
  <PhysicalSchema>
    <Table>
      <Key>
        <Column/>
      </Key>
    </Table>
    <Query>
      <SQL/>
    </Query>
    <InlineTable>
      <ColumnDefs>
        <ColumnDef/>
      </ColumnDefs>
      <Key/> <!-- same structure as Table/Key -->
      <Rows>
        <Row>
          <Value/>
        </Row>
      </Rows>
    </InlineTable>
    <Link/>
  </PhysicalSchema>


  <Dimension/> <!-- shared; same structure as Dimension within a Cube -->


  <Cube>
    <Dimensions>
      <Dimension>
        <Attributes>
          <Attribute>
            <Key>
              <Column/>
            </Key>
            <Name/>     <!-- same structure as Key -->
            <Caption/>  <!-- same structure as Key -->
            <OrderBy/>  <!-- same structure as Key -->
            <Closure/>
            <MemberFormatter>
              <Script/>
            </MemberFormatter>
            <Property>
              <PropertyFormatter>
                <Script/>
              </PropertyFormatter>
            </Property>
          </Attribute>
        </Attributes>
        <Hierarchies>
          <Hierarchy>
            <Levels>
              <Level/>
            </Levels>
          </Hierarchy>
        </Hierarchies>
      </Dimension>
    </Dimensions>


    <MeasureGroups>
      <MeasureGroup>
        <Measures>
          <Measure/>
          <MeasureRef/>
        </Measures>
        <DimensionLinks>
          <ForeignKeyLink/>
          <FactLink/>
          <ReferenceLink/>
          <CopyLink/>
          <NoLink/>
        </DimensionLinks>
      </MeasureGroup>
    </MeasureGroups>


    <CalculatedMembers>
      <CalculatedMember>
        <Formula/>
        <CalculatedMemberProperty/>
        <CellFormatter>
          <Script/>
        </CellFormatter>
      </CalculatedMember>
    </CalculatedMembers>


    <NamedSets>
      <NamedSet>
        <Formula/>
      </NamedSet>
    </NamedSets>
  </Cube>


  <Role>
    <SchemaGrant>
      <CubeGrant>
        <DimensionGrant/>
        <HierarchyGrant>
          <MemberGrant/>
        </HierarchyGrant>
      </CubeGrant>
    </SchemaGrant>
    <Union>
      <RoleUsage/>
    </Union>
  </Role>


  <UserDefinedFunction>
    <Script/>
  </UserDefinedFunction>


  <Parameter/>
</Schema>

L’ordre des éléments n’est pas significatif. Par exemple, un élément <UserDefinedFunction> peut apparaître avant un <Cube> et après un autre — Mondrian-4 parse le document positionnellement mais traite l’ordre des éléments comme indicatif. C’est un changement significatif par rapport à Mondrian 3.x, où l’ordre des éléments était strictement requis.

Le contenu de chaque élément est décrit dans les pages suivantes de cette section et dans la référence de schema YAML.

L’élément Schema

<Schema> est l’élément racine de chaque schema Mondrian. Un exemple minimal :

schema:
  name: "Rock Sales"
  metamodel_version: "4.0"

Attributs requis et courants

AttributRequisDéfautDescription
nameoui—Nom d’affichage pour ce schema
metamodelVersionnonauto-détectéVersion du format de schema. Utilisez "4.0" pour tous les nouveaux schemas
captionnon—Substituer le nom d’affichage vu par les outils clients
descriptionnon—Description lisible par humain
measuresCaptionnon—Légende pour la dimension virtuelle [Measures]
defaultRolenon—Rôle appliqué quand aucun rôle n’est spécifié par la connexion
quoteSqlnontrueSi Mondrian échappe les identifiants SQL
missingLinknonwarningComportement quand un lien de dimension manque — warning, error ou ignore
localesnon—Liste séparée par virgules de codes de locale pour les légendes localisées

L’attribut metamodelVersion indique à Mondrian pour quelle version le schema a été écrit. Si vous l’omettez, Mondrian infère la version à partir du contenu du schema. Pour tous les nouveaux schemas, définissez-le à "4.0".

Annotations

Les principaux types d’éléments — schema, cube, dimension partagée, dimension, attribut, hiérarchie, niveau, groupe de mesures, mesure, membre calculé — prennent tous en charge les annotations. Une annotation vous permet d’attacher des métadonnées clé/valeur arbitraires à n’importe quel élément de schema, ce qui est particulièrement utile pour les outils qui doivent stocker des informations sans modifier la définition officielle du schema Mondrian.

Ajoutez un élément <Annotations> comme enfant de l’élément que vous voulez annoter, puis incluez un ou plusieurs éléments <Annotation> à l’intérieur. Les valeurs name d’annotation doivent être uniques au sein de leur élément parent. Si vous créez des annotations pour un outil spécifique, choisissez les noms avec soin pour éviter les collisions avec d’autres outils.

schema:
  name: "Rock Sales"
  metamodel_version: "4.0"
annotations:
  Author: "Fred Flintstone"
  Date: "10,000 BC"
cubes:
  Sales:
    ...

Noms d’annotation conventionnels

Certains noms d’annotation sont utilisés par convention entre les outils :

AnnotationÉlément(s)Description
AnalyzerBusinessGroupLevelCrée des dossiers dans l’UI
AnalyzerBusinessGroupDescriptionLevelDescription pour ces dossiers
AnalyzerDateFormatLevelUtilisé pour les filtres de date relative
AnalyzerHideInUIMeasure, CalculatedMemberMasque le champ de l’UI
AnalyzerDisableDrillLinksCubeDésactive les liens de drillthrough sur le cube

Les outils sensibles à la locale utilisent des noms à qualification par point par convention — par exemple caption.de_DE pour une légende allemande, description.fr_FR pour une description française. Le schema de démo FoodMart montre ce pattern sur le cube Sales :

annotations:
  caption.de_DE: "Verkaufen"
  caption.fr_FR: "Ventes"
  description.fr_FR: "Cube des ventes"

Le modèle logique

Les composants les plus importants d’un schema sont les cubes, mesures, attributs et dimensions :

  • Un cube est un jeu de données décrivant un ou plusieurs processus métier sur une période de temps particulière.
  • Un fait est la donnée représentant une occurrence d’un processus — par exemple, une ligne décrivant la vente d’un produit à un client, ou une période de paie pour un employé.
  • Une mesure est une quantité que vous voulez agréger au sein d’un cube — par exemple, les ventes unitaires d’un produit, ou le salaire d’un employé.
  • Un attribut est une valeur, possédée par chaque fait, par laquelle vous pouvez diviser les faits en sous-ensembles. Vous pourriez découper les ventes de produits par couleur, genre du client, et magasin où le produit a été vendu ; couleur, genre et magasin sont tous des attributs.
  • Une dimension est un regroupement d’attributs liés. Par exemple, nom, genre, code postal et couleur des yeux sont des attributs d’une dimension Customer ; couleur, poids et fabricant sont des attributs d’une dimension Product.

Voici un exemple complet et fonctionnel d’un schema simple qui lie ces concepts ensemble :

schema:
  name: "Sales"
  metamodel_version: "4.0"
physical_schema:
  tables:
  - name: "sales_fact_1997"
  - name: "customer"
  - name: "time_by_day"
cubes:
  Sales:
    dimensions:
    - name: "Customer"
      table: "customer"
      key: "Id"
      attributes:
      - name: "Gender"
      - name: "Id"
    - name: "Time"
      table: "time_by_day"
      key: "Day"
      attributes:
      - name: "Year"
      - name: "Quarter"
        key:
        - "the_year"
        - "quarter"
      - name: "Month"
        key:
        - "the_year"
        - "month_of_year"
      - name: "Day"
      hierarchies:
      - name: "Yearly"
        has_all: false
        levels:
        - "Year"
        - "Quarter"
        - "Month"
    measure_groups:
    - name: "Sales"
      table: "sales_fact_1997"
      measures:
      - name: "Unit Sales"
        column: "unit_sales"
        aggregator: "sum"
        format_string: "#,###"
      - name: "Store Sales"
        column: "store_sales"
        aggregator: "sum"
        format_string: "#,###.##"
      - name: "Store Cost"
        column: "store_cost"
        aggregator: "sum"
        format_string: "#,###.00"
      dimension_links:
      - type: "foreign_key"
        dimension: "Customer"
        foreign_key_column: "customer_id"
      - type: "foreign_key"
        dimension: "Time"
        foreign_key_column: "time_id"
    calculated_members:
    - name: "Profit"
      dimension: "Measures"
      formula: "[Measures].[Store Sales] - [Measures].[Store Cost]"
      properties:
      - name: "FORMAT_STRING"
        value: "$#,##0.00"

Ce schema contient un seul cube appelé « Sales » avec deux dimensions (« Customer » et « Time »), trois mesures de base et un membre calculé (« Profit »). Vous pouvez écrire une requête MDX dessus immédiatement :

SELECT {[Measures].[Unit Sales], [Measures].[Store Sales]} ON COLUMNS,
       {Descendants([Time].[Yearly].[1997].[Q1])} ON ROWS
FROM [Sales]
WHERE [Customer].[Gender].[F]

Ce qui produit des résultats comme :

[Time][Measures].[Unit Sales][Measures].[Store Sales]
[1997].[Q1]32 91069 798,23 $
[1997].[Q1].[Jan]10 93223 309,04 $
[1997].[Q1].[Feb]10 26621 773,93 $
[1997].[Q1].[Mar]11 71224 715,26 $

Les sections qui suivent expliquent chaque partie de ce schema en détail.

Contenu adapté du guide de schema du projet Mondrian, disponible sous l’Eclipse Public License v1.0 (http://www.eclipse.org/legal/epl-v10.html).