Merkmalsbeziehungen

Merkmalsbeziehungen dienen dazu, inhaltlich korrespondierende Merkmale miteinander in Beziehung zu setzen. Mit Hilfe von Merkmalsbeziehungen können Sie Regeln definieren, um zulässige Kombinationen von Merkmalswerten pro Real-time-fähigen InfoCube oder pro DataStore-Objekt für direktes Schreiben im Planungsmodus zu überprüfen. Außerdem können Sie Regeln definieren, nach denen das System aus Merkmalen Werte für weitere Merkmale ableiten kann. Dies ist dann sinnvoll, wenn z.B. die ableitbaren Merkmale für weitere Auswertungen zur Verfügung stehen sollen.

Sie können Merkmalsbeziehungen zu den Stammdaten eines Merkmals (Typ Attribut), einer Hierarchie (Typ Hierarchie), einem DataStore-Objekt (Typ DataStore) oder einer Exit-Klasse (Typ Exit) definieren.

Ein DataStore-Objekt für direktes Schreiben im Planungsmodus hat im Gegensatz zu einen InfoCube einen Schlüssel. Über die BW-integrierte Planung können Datensätze neu eingefügt oder verändert werden. In jedem Fall muss dazu der Schlüssel gefüllt werden können. Damit nicht jede Aggregationsebene immer auch alle Merkmale des Schlüssels enthalten muss, können ggf. über Merkmalsbeziehungen Schlüsselfelder aus anderen Merkmalen abgeleitet werden.

Integration

Wenn Merkmalsbeziehungen in bezug auf Attribute und Hierarchien zu Merkmalen definiert werden, stellt das System diejenigen Attribute und Hierarchien zur Auswahl, die im BW-System zu einem Merkmal angelegt wurden (siehe Registerkarte: Attribute sowie Registerkarte: Hierarchie und Hierarchie).

Merkmalsbeziehungen werden zu einem Real-time-fähigen InfoCube oder einem DataStore-Objekt für direktes Schreiben im Planungsmodus angelegt. Sie wirken sich dann in allen für die Planung relevanten InfoProvidern aus, die diesen InfoProvider referenzieren.

Jede eingabebereite Query und jede Planungsfunktion berücksichtigt damit automatisch die Merkmalsbeziehungen:

In einer eingabebereiten Query sind Zellen zu ungültigen Merkmalskombinationen nicht eingabebereit, und neue Datensätze mit ungültigen Merkmalskombinationen können nicht erzeugt werden.
Planungsfunktionen überprüfen stets, ob neue Merkmalskombinationen entsprechend den Merkmalsbeziehungen gültig sind. Im Fall von ungültigen Kombinationen teilt das System dies durch eine Fehlermeldung mit.

Die möglichen Merkmalsableitungen finden bei der Ermittlung der Delta-Sätze im Delta-Buffer (für den InfoCube) oder im After-Image-Buffer (für das DataStore-Objekt) statt. Die möglichen Quellmerkmale sind hier die Merkmale des planungsrelevanten InfoProviders, die von Merkmalen aus den beteiligten Aggregationsebenen gefüllt werden. Wenn Merkmalsbeziehungen geändert werden, müssen ggf. Datensätze im planungsrelevanten InfoProvider auf die neue Struktur angepasst werden. Hierzu dient die Planungsfunktion Umbuchen Merkmalsbeziehungen.

Voraussetzungen

Um Merkmalsbeziehungen definieren zu können, müssen folgende Voraussetzungen erfüllt sein:

Der InfoProvider muss ein Real-time-fähiger InfoCube oder ein DataStore-Objekt für direktes Schreiben im Planungsmodus sein. Die definierten Merkmalsbeziehungen sind auch in MultiProvidern wirksam, in denen die planungsrelevanten InfoProvider verwendet werden. Siehe InfoProvider.
Bei Merkmalsbeziehungen vom Typ Attribut muss das Zielmerkmal als Attribut des Basismerkmals definiert und selbst im planungsrelevanten InfoProvider enthalten sein.
Bei Merkmalsbeziehungen vom Typ Hierarchie muss das Zielmerkmal in der ausgewählten Hierarchie und im planungsrelevanten InfoProvider enthalten sein. Die Hierarchie ist hauptsächlich zur Modellierung einer Ableitungsbeziehung gedacht; daher darf die Hierarchie kein Blatt und keinen inneren Knoten mehrfach enthalten. Link-Knoten sind ebenfalls nicht zulässig.
Bei Merkmalsbeziehungen vom Type DataStore sind nur Standard-DataStore-Objekte zulässig. Daher kann man hier alle Methoden zur Administration und zum Monitoring der Data Warehousing Workbench nutzen.

Funktionsumfang

Definition einer Merkmalsbeziehung

Merkmalsbeziehungen können Sie zu einem Real-time-fähigen InfoCube oder einem DataStore-Objekt für direktes Schreiben im Planungsmodus anlegen. Eine Merkmalsbeziehung besteht aus einer Menge von Relationen (Schritten), die einfach fortlaufend nummeriert werden. Jede dieser Relationen setzt eine Menge von Merkmalen in Beziehung. Diese Relationen stellen die kleinsten Einheiten einer Merkmalsbeziehung dar.

Verhalten bei Kombinationsprüfung ohne und mit Ableitung

Relationen können ausschließlich zur Prüfung von Merkmalskombinationen oder zusätzlich auch zu einer Merkmalsableitung dienen. Sie legen dieses Verhalten bei der Definition einer Relation fest. Insbesondere bei Relationen vom Typ Ableitung können Beziehungen unter Relationen dadurch hergestellt werden, dass Zielmerkmale einer Relation Quellmerkmale einer anderen Relation sind. Dabei sollten Redundanzen vermieden werden, damit die Relationen wirklich die kleinsten Einheiten der Merkmalsbeziehungen darstellen.

Das System ermittelt zur Laufzeit, welche Relationen der Merkmalsbeziehungen in den InfoProvidern, die für die Planung relevant sind, zur Anwendung gelangen.

Kombinationsprüfung: Eine Relation kommt dann in einer Aggregationsebene zur Anwendung, wenn jedes Merkmal der Relation in der Aggregationsebene vorkommt. Bei Ableitungen sind dies die Quell- und Zielmerkmale; in diesem Fall wird nichts abgeleitet, die Relation wirkt nur als Kombinationsprüfung.
Merkmalsableitung: Innerhalb einer Aggregationsebene findet keine Ableitung statt. Ableitungen erfolgen nur für Sätze des planungsrelevanten InfoProviders. Zunächst ermittelt das System die Menge S der Merkmale, die von der beteiligten Aggregationsebene versorgt werden. Das System wendet dann diejenigen Ableitungsrelationen an, deren sämtliche Quellmerkmale in der Menge S enthalten sind. Die Zielmerkmale dieser Ableitungen können dann wiederum in folgenden Schritten als Quellen dienen. Insofern führt das System auf der Ebene des planungsrelevanten InfoProviders die maximal mögliche Ableitung durch. Wenn bereits abgeleitete Merkmalswerte in nachfolgenden Schritten erneut verändert werden, ist die Ableitung fehlerhaft. Das System gibt eine entsprechende Fehlermeldung aus.

Typen von Merkmalsbeziehungen

Es gibt folgende Typen von Merkmalsbeziehungen:

Typ	Weitere Informationen
Attribut	Als Zielmerkmal sind die Attribute des Basismerkmals auswählbar (z.B. ist das Merkmal Währung ein Attribut des Merkmals Kostenrechnungskreis). Die vorhandenen Kombinationen aus Merkmals- und Attributswerten werden als zulässige Kombinationen interpretiert.
Hierarchie	Als Quell- bzw. Zielmerkmale sind alle Merkmale verfügbar, die in der InfoObject Pflege als Externe Merkmale in Hierarchie festgelegt wurden. Die Hierarchie muss neben dem Hierarchiebasismerkmal mindestens ein weiteres Merkmal enthalten. Als Quell- bzw. Zielmerkmal ist jeweils nur ein Merkmal erlaubt (hierbei werden die übergeordneten Merkmale bei geklammerten Merkmale nicht mitgezählt). Die zulässigen Kombinationen werden aus der Hierarchiestruktur entnommen. Dieselbe Hierarchie kann in mehreren Relationen verwendet werden: In einem Schritt leitet man aus dem Hierarchiebasismerkmal ein Merkmal auf der nächst höheren Ebene ab; in einem zweiten Schritt aus diesem Merkmal, dann wieder ein Merkmal aus der nächsten Ebene. Die verwendeten Hierarchien können je nach der Eigenschaft der Hierarchie mit den passenden Variablen parametrisiert werden.
DataStore	Die im DataStore enthaltenen Datensätze legen die gültigen Merkmalskombinationen fest bzw. dienen zur Merkmalsableitung. Nur Kombinationsprüfung: Es können alle InfoObjects des DataStore-Objektes (außer Kennzahlen) ausgewählt werden. Mit Ableitung: Als Quellmerkmale sind genau die Schlüssel des DataStore-Objektes auszuwählen. Zielmerkmale können InfoObjects aus dem Datenteil des DataStore-Objektes (außer Kennzahlen) sein. Die Schlüssel des DataStore-Objektes können in jedem Fall mit einer Einschränkung versehen werden; es wird dann der durch diese Einschränkungen festgelegte Teil zur Kombinationsprüfung bzw. Ableitung herangezogen. Die Einschränkungen können mit Variablen, die ohne Dialog ersetzbar sein müssen, parametrisiert werden. Wir empfehlen, nur kleine DataStore-Objekte (mit wenigen Merkmalen, wenigen Sätzen) zu verwenden.
Exit	Die gültigen Merkmalskombinationen bzw. ableitbaren Merkmalswerte ergeben sich aus der kundenspezifischen Implementierung der angegebenen Exit-Klasse. Die Exit-Klasse muss das Interface ‚IF_RSPLS_CR_EXIT’ implementieren; in der Pflege werden nur solche Klassen zur Bearbeitung angeboten. Wir empfehlen, die eigene Klasse von der Beispielklasse ‚CL_RSPLS_CR_EXIT_BASE’ abzuleiten. Sie müssen dann nur die Methoden ‚CHECK’, ‚DERIVE’ und ggf. ‚CREATE’ implementieren. Die Klasse ‚CL_RSPLS_CR_EXIT_BASE’ selbst ist direkt lauffähig, führt jedoch noch keine Aktion aus. Beachten Sie auch den auskommentierten Beispiel-Quelltext in der Vorlageklasse; dort wird z.B. eine Infrastruktur für eine Pufferung angeboten.

Hinweis Hinweis

Neben den oben genannten Merkmalsbeziehungen, die Sie bearbeiten können, sind im System stets weitere Merkmalsbeziehungen für die BW-Zeitmerkmale aktiv (siehe Merkmalsbeziehungen für Zeitmerkmale).

Ende des Hinweises

Innerhalb einer Relation ist zu beachten, dass der initiale Merkmalswert (# nicht zugeordnet) eine besondere Rolle spielt. Das hängt damit zusammen, dass Merkmale, die nicht in einer Aggregationsebene vorkommen (und nicht ableitbar sind) mit dem Initialwert fortgeschrieben werden.

Beispiel

Kombinationsprüfung ohne Ableitung:

Gegeben sei eine Relation zwischen den Merkmalen Produkt und Sortiment, hier besteht im allgemeinen keine Ableitungsbeziehung. In Aggregationsebenen mit Produkt ohne Sortiment wird daher Sortiment mit dem Initialwert fortgeschreiben. Solche Kombinationen sind somit immer gültig; sie können nicht verboten werden. Entsprechendes gilt für Kombinationen mit dem Initialwert für Produkt.

Kombinationsprüfung mit Ableitung:

Gegeben sei eine Relation zwischen den Merkmalen Kostenstelle und Profitcenter, hierbei ist Profitcenter aus Kostenstelle ableitbar. In einer Aggregationsebene mit Profitcenter ohne Kostenstelle wird jedoch ebenfalls die Kostenstelle mit dem Initialwert fortgeschrieben. Solche Kombinationen können nicht verboten werden. Die Umkehrung gilt hier aber wegen der möglichen Ableitung von Profitcenter aus Kostenstelle nicht.

Ende des Beispiels.

Aktivitäten

Weitere Informationen über das Definieren von Merkmalsbeziehungen im Planning Modeler finden Sie unter Merkmalsbeziehungen definieren].