Show TOC

Schreiboptimiertes DataStore-ObjektLocate this document in the navigation structure

DataStore-Objekt, das nur aus einer Tabelle der aktiven Daten besteht. Die Daten werden über den Datentransferprozess geladen.

Verwendung

Daten, die in schreiboptimierte DataStore-Objekte geladen werden, stehen sofort für die Weiterverarbeitung zur Verfügung.

Als Einsatzgebiet sind folgende Szenarios denkbar:

  • Sie setzen ein schreiboptimiertes DataStore-Objekt als Zwischenlager für große Mengen von Daten ein, auf denen Sie komplexe Transformationen ausführen, bevor sie in das DataStore-Objekt geschrieben werden. Anschließend können die Daten in weitere (kleinere) InfoProvider fortgeschrieben werden. Die komplexe Transformation muss dann nur einmal für alle Daten angelegt werden.

  • Sie nutzen schreiboptimierte DataStore-Objekte als EDW-Ebene zur Speicherung aller Daten. Erst bei der Fortschreibung der Daten in weitere InfoProvider werden betriebswirtschaftliche Regeln angewandt.

Für das schreiboptimierte DataStore-Objekt werden keine SIDs erzeugt, und es ist keine Aktivierung nötig. Dadurch können die Daten schneller gespeichert und weiterverarbeitet werden. Obwohl BEx Queries auf diesem DataStore-Objekt möglich ist, empfehlen wir, es eher als Konsolidierungsebene zu verwenden, und die Daten von dort aus in weitere InfoProvider, Standard-DataStore-Objekte oder InfoCubes, fortzuschreiben.

Struktur

Da das schreiboptimierte DataStore-Objekt nur aus der Tabelle der aktiven Daten besteht, entfällt die beim Standard-DataStore-Objekt nötige Aktivierung der Daten. Die Daten werden dadurch schneller verarbeitet.

Es findet keine Aggregation der geladenen Daten statt, dadurch wird die Historie der Daten erhalten. Werden zwei Datensätze mit gleichem logischen Schlüssel aus der Quelle extrahiert, so werden beide Sätze im DataStore-Objekt gespeichert. Der für die Aggregation verantwortliche Recordmode bleibt jedoch erhalten, so dass die Aggregation der Daten zu einem späteren Zeitpunkt in Standard-DataStore-Objekten stattfinden kann.

Technischer Schlüssel

Das System generiert für das schreiboptimierte DataStore-Objekt einen eindeutigen technischen Schlüssel. Die Standard-Schlüsselfelder sind bei diesem Typ nicht unbedingt erforderlich. Bestehen trotzdem Standard-Schlüsselfelder, so werden sie zur Unterscheidung von diesem technischen Schlüssel semantischer Schlüssel genannt. Der technische Schlüssel besteht aus den Feldern Request GUID (0REQUEST), Datenpaket (0DATAPAKID) und Datensatznummer (0RECORD). Zu diesem Schlüssel werden immer nur neue Datensätze geladen.

Doppelte Datensätze

Sie können angeben, dass doppelte Datensätze zugelassen werden (die Eindeutigkeit der Daten wird dann nicht geprüft). Wenn Sie doppelte Datensätze zulassen, dann können in der aktiven Tabelle des DataStore-Objektes mehrere Sätze mit demselben Schlüssel enthalten sein. Wenn Sie dieses Kennzeichen nicht setzen, und die Eindeutigkeit prüfen lassen, dann wird für die InfoObjects im semantischen Schlüssel ein eindeutiger Index mit dem technischen Namen "KEY" generiert. Da das schreiboptimierte DataStore-Objekt kein Change Log besitzt, werden keine Deltas im Sinne von Before- und After-Images erzeugt. Beim Fortschreiben der Daten in angeschlossene InfoProvider werden nur Requests fortgeschrieben, die dort noch nicht verbucht sind.

Delta-Konsistenzprüfung

Das schreiboptimierte DataStore-Objekt wird oft wie ein PSA eingesetzt. Daten, die ins DataStore-Objekt geladen und danach aus der Data-Warehouse-Schicht abgeholt wurden, sollen nach einer angemessenen Verweildauer wieder gelöscht werden.

Wenn Sie das DataStore-Objekt allerdings als Teil der Konsistenzschicht einsetzen, dann dürfen bereits fortgeschriebene Daten nicht gelöscht werden. Die Delta-Konsistenzprüfung des DTP-Deltamanagements verhindert, dass ein bereits per Delta abgeholter Request gelöscht wird. Das Kennzeichen Delta-Konsistenzprüfung in den Einstellungen des schreiboptimierten DataStore-Objekts ist per Voreinstellung ausgeschaltet. Wenn Sie das DataStore-Objekt als Teil der Konsistenzschicht einsetzen, empfiehlt es sich, die Delta-Konsistenzprüfung einzuschalten. Dann wird für dieses DataStore-Objekt beim Löschen eines Requests geprüft, ob die Daten bereits per Delta fortgeschrieben wurden. In diesem Fall kann der Request nicht gelöscht werden.

Asynchrones Löschen

Sie können Sätze aus einem schreiboptimierten DataStore-Objekt asynchron löschen. Sie sollten dabei beachten, dass, wenn das DataStore-Objekt in einer Transformationsregel für das Nachlesen verwendet wird, die Löschungen nicht berücksichtigt werden, so lange die Reorganisation der Sätze nicht erfolgt ist.

Verwendung in BEx Queries

Aus Performancegründen werden keine SID-Werte für die geladenen Merkmale erzeugt. Die Daten stehen trotzdem für BEx Queries zur Verfügung. Allerdings muss hierbei im Vergleich zu Standard-DataStore-Objekten mit Performanceeinbußen gerechnet werden, da dafür während der Auswertung die notwendigen SID-Werte erzeugt werden.

Wenn Sie schreiboptimierte DataStore-Objekte in BEx Queries verwenden möchten, empfehlen wir, dass diese einen semantischen Schlüssel haben sollten und dass die Eindeutigkeit der Daten geprüft wird. In diesem Fall verhält sich das schreiboptimierte DataStore-Objekt wie ein Standard-DataStore-Objekt. Wenn das DataStore-Objekt diese Eigenschaften nicht hat, kann es durch die Aggregation in der Query zu unerwarteten Ergebnissen kommen.

DataStore-Daten und externe Applikationen

Das BAPI BAPI_ODSO_READ_DATA_UC zum Lesen von Daten ermöglicht es Ihnen, DataStore-Daten externen Systemen zur Verfügung zu stellen.

Im vorherigen Release wurde dafür das BAPI BAPI_ODSO_READ_DATA eingesetzt. Dieses ist nun obsolet.