↓ Zum Inhalt
Hyperion im Klartext

Hyperion im Klartext

  • Startseite
  • BeitrĂ€ge
  • Warum ein Blog
  • Wer wir sind
  • Kontakt

Enterprise Data Management Cloud Teil 2.

Posted on 29.09.2021 by Philip Hulsebosch

Die Enterprise Data Management Cloud (EDM) ist das Meta-Daten Management der EPM Enterprise Cloud. In Teil 1 habe ich die Erstellung einer Anwendung und das Importieren von Dimensionen darin besprochen. In diesem Beitrag gehe ich in die Tiefe mit der Definition von Node Types, Hierarchiën und Eigenschaften.

In dem dritten und letzten Beitrag zu diesem Thema zeige ich Regeln, Validierungen und vieles Mehr.

Kurzer RĂŒckblick

EDM dient zur Pflege von Dimensionen, Hierarchieen und Attribute (auch Stammdaten Management genannt). Dieses ist selbstverstĂ€ndlich mit vielen Funktionen umgeben und Benutzerfreundlich gestaltet. Meta-Daten Management ist in grösseren Umgebungen mit vielen Änderungen eine Arbeitsintensive, oft mit Fehlern behaftete TĂ€tigkeit. Daher ist ein Werkzeug, welches hierfĂŒr speziell entwickelt wurde, eine gute Hilfe.

Ich hatte die Möglicheit, um bei einer Partnerschulung diese Software mir mal nĂ€her anzusehen und vorallem auch auszuprobieren. Mit einigem Hintergrundwissen von DRM, aber vorallem EPMA konnte ich mich schnell zurecht finden und habe in diesem Beitrag und in einem Weiteren einen „Mitschnitt“ der TĂ€tigkeiten gemacht.

Es geht weiter mit Nodes, Hierarchiën und Eigenschaften

In dem Desktop sehen sie die Kacheln fĂŒr die Node Type, Hierarchy Sets, Node Sets und Properties. Diese bilden das HerzstĂŒck des EDMC und wir werden diese hiernach erlĂ€utern.

Abbildung 1: Desktop eines Admin in Enterprise Data Management

Node Types.

Node Types sind in EPM Dimensionen und umfassen Nodes mit den daran verbundenen Eigenschaften. Zum Beispiel, die Node Type Entity enthÀlt die EntitÀten mit ihren Eigenschaften wie WÀhrung und Alias.

In Abbildung 2 sehen sie eine Liste Node Types. Beim Erstellen eines Node Types muss diese einer Anwendung zugeordnet werden. Der sechste Eintrag, die blau unterlegte Entity, wurde in dem vorigen Beitrag angelegt.

Abbildung 2: Node Types

Wir schauen uns einmal den Planning Node Type „Product“ nĂ€her an.

Nach dem Öffnen sehen wir wie in Abbildung 3 einige Reiter mit den Definitionen dieser Dimension. So gibt es einen PrĂ€fix und es ist ersichtlich wer Anpassungen gemacht hat.

Abbildung 3: Node Type Product

In dem Reiter Properties sehen wir die Liste der Eigenschaften, die mit der Dimension und dem Planungstyp verbunden sind. Dieses sind generische Eigenschaften, die dieser Dimension zugeordnet wurden. In diesem Fenster können diese als Pflichtangabe eingestellt werden oder nicht.

Abbildung 4: Node Type Properties

Wir gehen noch ein Level tiefer und sehen uns in Abbildung 5 die Eigenschaften von PLN.Alias: Default an. Die Eigenschaften haben eine Basis-Definition von einer maximalen LĂ€nge von 80 Zeichen (nicht in der Abbildung) und bestimmte Zeichen sind verboten wie AnfĂŒhrungszeichen oder Tab.

Die BeschrĂ€nkungen gelten ĂŒberall, wo das PLN.Alias: Default eingesetzt wird. Somit kann es einmal definiert werden und ĂŒberall wiederverwendet werden.

Abbildung 5: Eigenschaften von PLN.Alias: Default

Hierarchy Sets

Bei dem Anlegen der Verbindung mit der Planning Cloud, und dem Verbinden der Entity, wurde auch ein Eintrag in den Hierarchy Sets gemacht.

Abbildung 6: Hierarchy Sets.

Und die verschiedenen Reiter, um diese Dimension weiter zu definieren. Hier können Validierungen gesetzt werden, dass bestimmte Parent-Child Kombinationen nicht erlaubt sind. So kann man definieren, dass es keine Shared Member in der Entity Dimension geben kann.

Abbildung 6: Keine Restriktionen in den Membern von Entity.

Node Set

In einem Node Set kann eine Gruppe von Node Types und/oder Top Nodes verwaltet werden. Es ist ein gespeicherter Filter, damit nicht immer wieder eine Selektion auf die Arbeitswiese gemacht werden muss.

Wir sehen bei der Definition von Entity, wurde auch ein Node Set angelegt.

Abbildung 7: Node Sets.

Properties

Die Properties sind die Eigenschaften von Dimensionen, Elemente und anderen Objekten. Diese können hier Zentral definiert und dann in gleichartige Objekte wiederverwendet werden. Die Properties sind eine der wichtigsten Bausteine in Dimensionsmanagement und kommen vordefiniert mit ECMCS.

In Abbildung 5 wurden bereits die Eigenschaften von PLN.Alias: Default dargestellt und gezeigt wie diese eingesetzt werden können. In Abbildung 8 sind weitere gezeigt. Das PLN steht fĂŒr Planning und das OEP in Klammern fĂŒr das Oracle Enterprise Planning.

Abbildung 8: Die Properties oder Eigenschaften.

Abbildung 9: Die Eigenschaften fĂŒr PLN.Account Type

In den Eigenschaften sehen wir als Erlaubte Werte dann die bekannten Expense, Revenue, Asset, Liability, Equity und Saved Assumptions. Hiermit können wir Regeln erstellen, dass einer dieser erlaubten Werte zu einem Element der Account Dimension gesetzt sein muss. Andere Werte fĂŒhren zu einem Fehler.

Abbildung 10: Werte Tabelle in den Properties.

Damit sind wir am Ende des zweiten Teils gekommen.

Ihr Philip Hulsebosch.

Ähnliche BeitrĂ€ge

  • Enterprise Data Management Cloud
  • AnkĂŒndigung: Oracle Essbase Cloud Service
  • Oracle Hyperion Planning Cloud (PBCS) fĂŒr Frittenbuden?
‹ Börsendaten in Oracle Data Visualization darstellen
Enterprise Data Management Cloud Teil 3. ›
Veröffentlicht in EPM Cloud Verwendete Schlagwörter: Data Governance, DRM, EDM, EPM, EPM Cloud, EPMA, Meta Data, Stammdaten

Suche

Tools & Themen

  • Bewirtschaftung & Automatisierung (21)
  • EPM & BI (43)
  • EPM Cloud (34)
  • Essbase (163)
  • Installation, Konfiguration & Tuning (44)
  • OBIEE (1)
  • Planung & Berichtswesen (50)
  • Versionen – Was ist neu? (31)
    • EPM – 11.1.2.3 (13)
    • EPM – 11.1.2.4 (4)
    • EPM – 11.1.2.5 (5)
    • EPM – 11.2 (8)

Service

  • Downloads & Links

RSS Oracle – Proactive Support

Stichworte

11.1.2.4 Alias ASO Datenbank BenutzeroberflÀche Cloud Deployment Dimension Dimensionen Dodeca EAS EPBCS EPM EPMA EPM Automate epmautomate EPM Cloud Essbase Essbase Cloud EssCS Excel Excel Add-In Export Fehler Formulare Hyperion Planning Installation Konfiguration LCM MaxL Oracle Cloud Outline PBCS Planning Planning Cloud Planung Report Reporting Skript Smart View SmartView Smart View Formatierung Unicode Upgrade UTF-8 Version

Archiv

  • MĂ€rz 2023
  • Januar 2023
  • Dezember 2022
  • November 2022
  • September 2022
  • Juni 2022
  • Mai 2022
  • April 2022
  • Dezember 2021
  • Oktober 2021
  • September 2021
  • August 2021
  • Juni 2021
  • Mai 2021
  • April 2021
  • MĂ€rz 2021
  • Februar 2021
  • Januar 2021
  • Dezember 2020
  • November 2020
  • Oktober 2020
  • September 2020
  • August 2020
  • Juni 2020
  • Mai 2020
  • April 2020
  • MĂ€rz 2020
  • Februar 2020
  • Januar 2020
  • Dezember 2019
  • November 2019
  • Oktober 2019
  • September 2019
  • August 2019
  • Juli 2019
  • Juni 2019
  • Mai 2019
  • April 2019
  • MĂ€rz 2019
  • Februar 2019
  • Januar 2019
  • Dezember 2018
  • November 2018
  • Oktober 2018
  • September 2018
  • August 2018
  • Juli 2018
  • Juni 2018
  • Mai 2018
  • April 2018
  • MĂ€rz 2018
  • Februar 2018
  • Januar 2018
  • Dezember 2017
  • November 2017
  • Oktober 2017
  • August 2017
  • Juli 2017
  • Juni 2017
  • Mai 2017
  • April 2017
  • MĂ€rz 2017
  • Februar 2017
  • Januar 2017
  • Dezember 2016
  • November 2016
  • Oktober 2016
  • September 2016
  • August 2016
  • Juli 2016
  • Juni 2016
  • Mai 2016
  • April 2016
  • MĂ€rz 2016
  • Februar 2016
  • Januar 2016
  • Dezember 2015
  • November 2015
  • Oktober 2015
  • September 2015
  • Juli 2015
  • Juni 2015
  • Mai 2015
  • April 2015
  • MĂ€rz 2015
  • Februar 2015
  • Januar 2015
  • Dezember 2014
  • November 2014
  • Oktober 2014
  • September 2014
  • August 2014
  • Juli 2014
  • Juni 2014
  • Mai 2014
  • April 2014
  • MĂ€rz 2014
  • RSS-Feed
© 2023 Hyperion im Klartext
↑
Responsive Theme powered by WordPress