Zum Inhalt springen
Saiku Cloud

Schema-Struktur

Ein vollständiges Beispiel

Hier ist ein kleines, aber vollständiges Mondrian-4-Schema — ein Cube, eine Dimension, zwei Measures. Saiku akzeptiert Schemas entweder in YAML (Standard) oder XML; wählen Sie unten ein Format, und jedes Beispiel auf der Seite wechselt entsprechend.

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"

Struktur eines Schemas

Die Gesamtstruktur eines Mondrian-4-Schema-XML-Dokuments sieht so aus:

<Schema>
  <PhysicalSchema>
    <Table>
      <Key>
        <Column/>
      </Key>
    </Table>
    <Query>
      <SQL/>
    </Query>
    <InlineTable>
      <ColumnDefs>
        <ColumnDef/>
      </ColumnDefs>
      <Key/> <!-- gleiche Struktur wie Table/Key -->
      <Rows>
        <Row>
          <Value/>
        </Row>
      </Rows>
    </InlineTable>
    <Link/>
  </PhysicalSchema>


  <Dimension/> <!-- shared; gleiche Struktur wie Dimension innerhalb eines Cubes -->


  <Cube>
    <Dimensions>
      <Dimension>
        <Attributes>
          <Attribute>
            <Key>
              <Column/>
            </Key>
            <Name/>     <!-- gleiche Struktur wie Key -->
            <Caption/>  <!-- gleiche Struktur wie Key -->
            <OrderBy/>  <!-- gleiche Struktur wie 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>

Die Elementreihenfolge ist nicht signifikant. Zum Beispiel kann ein <UserDefinedFunction>-Element vor einem <Cube> und nach einem anderen erscheinen — Mondrian-4 parst das Dokument positional, behandelt die Elementreihenfolge aber als beratend. Dies ist eine bedeutende Änderung gegenüber Mondrian 3.x, wo die Elementreihenfolge strikt erforderlich war.

Der Inhalt jedes Elements wird auf den folgenden Seiten dieses Abschnitts und in der YAML-Schema-Referenz beschrieben.

Das Schema-Element

<Schema> ist das Wurzelelement jedes Mondrian-Schemas. Ein minimales Beispiel:

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

Erforderliche und gängige Attribute

AttributErforderlichStandardBeschreibung
nameja—Anzeigename für dieses Schema
metamodelVersionneinauto-erkanntSchemaformat-Version. Verwenden Sie "4.0" für alle neuen Schemas
captionnein—Überschreibt den von Client-Tools gesehenen Anzeigenamen
descriptionnein—Menschenlesbare Beschreibung
measuresCaptionnein—Caption für die virtuelle [Measures]-Dimension
defaultRolenein—Rolle, die angewendet wird, wenn von der Verbindung keine Rolle angegeben ist
quoteSqlneintrueOb Mondrian SQL-Bezeichner in Anführungszeichen setzt
missingLinkneinwarningVerhalten, wenn ein Dimension-Link fehlt — warning, error oder ignore
localesnein—Kommagetrennte Liste von Locale-Codes für lokalisierte Captions

Das metamodelVersion-Attribut teilt Mondrian mit, für welche Version das Schema geschrieben wurde. Wenn Sie es weglassen, leitet Mondrian die Version aus dem Schema-Inhalt ab. Für alle neuen Schemas setzen Sie es auf "4.0".

Annotationen

Die wichtigsten Elementtypen — Schema, Cube, Shared Dimension, Dimension, Attribute, Hierarchy, Level, Measure-Gruppe, Measure, Calculated Member — unterstützen alle Annotationen. Eine Annotation lässt Sie beliebige Schlüssel/Wert-Metadaten an jedes Schema-Element anhängen, was besonders nützlich für Tools ist, die Informationen speichern müssen, ohne die offizielle Mondrian-Schema-Definition zu ändern.

Fügen Sie ein <Annotations>-Element als Kind des Elements hinzu, das Sie annotieren möchten, und schließen Sie dann ein oder mehrere <Annotation>-Elemente darin ein. name-Werte von Annotationen müssen innerhalb ihres Elternelements eindeutig sein. Wenn Sie Annotationen für ein bestimmtes Tool erstellen, wählen Sie Namen sorgfältig, um Konflikte mit anderen Tools zu vermeiden.

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

Konventionelle Annotationsnamen

Einige Annotationsnamen werden konventionell über Tools hinweg verwendet:

AnnotationElement(e)Beschreibung
AnalyzerBusinessGroupLevelErstellt Ordner in der UI
AnalyzerBusinessGroupDescriptionLevelBeschreibung für diese Ordner
AnalyzerDateFormatLevelFür relative Datumsfilter verwendet
AnalyzerHideInUIMeasure, CalculatedMemberVersteckt das Feld vor der UI
AnalyzerDisableDrillLinksCubeDeaktiviert Drillthrough-Links auf dem Cube

Locale-bewusste Tools verwenden konventionell punktqualifizierte Namen — zum Beispiel caption.de_DE für eine deutsche Caption, description.fr_FR für eine französische Beschreibung. Das FoodMart-Demoschema zeigt dieses Muster auf dem Sales-Cube:

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

Das logische Modell

Die wichtigsten Komponenten eines Schemas sind Cubes, Measures, Attribute und Dimensionen:

  • Ein Cube ist ein Datensatz, der einen oder mehrere Geschäftsprozesse über einen bestimmten Zeitraum beschreibt.
  • Ein Fakt sind die Daten, die ein Vorkommen eines Prozesses darstellen — zum Beispiel ein Posten, der den Verkauf eines Produkts an einen Kunden beschreibt, oder eine Abrechnungsperiode für einen Mitarbeiter.
  • Ein Measure ist eine Menge, die Sie innerhalb eines Cubes aggregieren möchten — zum Beispiel Verkaufsstück eines Produkts oder das Gehalt eines Mitarbeiters.
  • Ein Attribut ist ein Wert, den jedes Fakt besitzt, mit dem Sie Fakten in Teilmengen unterteilen können. Sie könnten Produktverkäufe nach Farbe, Kundengeschlecht und dem Store schneiden, in dem das Produkt verkauft wurde; Farbe, Geschlecht und Store sind alle Attribute.
  • Eine Dimension ist eine Gruppierung verwandter Attribute. Zum Beispiel sind Name, Geschlecht, Postleitzahl und Augenfarbe Attribute einer Customer-Dimension; Farbe, Gewicht und Hersteller sind Attribute einer Product-Dimension.

Hier ist ein vollständiges, funktionierendes Beispiel eines einfachen Schemas, das diese Konzepte verbindet:

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"

Dieses Schema enthält einen einzelnen Cube namens „Sales” mit zwei Dimensionen („Customer” und „Time”), drei Basis-Measures und einem Calculated Member („Profit”). Sie können sofort eine MDX-Abfrage dagegen schreiben:

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

Was Ergebnisse wie diese erzeugt:

[Time][Measures].[Unit Sales][Measures].[Store Sales]
[1997].[Q1]32.910$69.798,23
[1997].[Q1].[Jan]10.932$23.309,04
[1997].[Q1].[Feb]10.266$21.773,93
[1997].[Q1].[Mar]11.712$24.715,26

Die folgenden Abschnitte erklären jeden Teil dieses Schemas im Detail.

Inhalt übernommen aus dem Mondrian-Projekt-Schema-Guide, verfügbar unter der Eclipse Public License v1.0 (http://www.eclipse.org/legal/epl-v10.html).