Hallo BI-Freunde,

ich beschäftige mich monentan etwas mit schreiboptimierten DataStores. Vielleicht könnt ihr mir folgende Fragen beantworten:

- Welche Funktion haben die "semantischen Schlüsselfelder" bei schreibopt. DataStores?
- Wie stark steigt das Datenvolumen bei Verwendung von schreibopt. DataStores? Habt ihr irgendwelche Vergleichswerte oder Erfahrungswerte?
- Gibt es sowas wie eine Faustformel oder einen Anhaltspunkt, wann schreibopt. DataStores verwendet werden sollten und wann nicht?

Danke schonmal.

- welche Funktion semantische Schlüsselfelder haben ist an dieser Stelle vielleicht die falsche Frage, sondern eher was sind sie. Bei schreiboptimierten DSOs muss man keine Schlüsselfelder angeben (der technische wird natürlich automatisch generiert), tut man es doch ist dies der semantische Schlüssel.

- Wie stark steigt das Datenvolumen? Falsche Frage 😉 Das Datenvolumen bleibt immer gleich und ist abhängig von der Granularität. Hingegen braucht ein Standard DSO mehr Speicherkapazität (wenn wir von der gleichen Anzahl an Feldern und Datensätzen ausgehen) da dieser aus drei Tabellen (aktiv, changelog + activation queue) besteht 😉

- Allgemein sagt man: Bei sehr großen Datenmengen schreiboptimierter DSO (ist jedoch nicht so sehr fürs Reporting geeignet). Man kann nicht pauschal sagen was besser ist, und es muss immer im Einzelfall geprüft werden (Anzahl der Felder, Datensätze + Verwendungszweck + DataSource (Delta oder nicht)).

Grüße

danke für die schnelle antwort.

- Der semantische Schlüssel ersetzt dann den sonst automatisch generierten techn. Schlüssel? Der semantische Schlüssel müsste trotzdem immer eindeutig sein, wegen der 1:1 Beziehung?
- Erhöhen schreibopt. DSO´s nicht automatisch das Datenvolumen, da sie keine anderen Objekte/Provider ersetzen, sondern eher eine zusätzliche Ebene darstellen?
- Du sagst, es muss immer im Einzelfall geprüft werden, zb. anhand der Anzahl der Datensätze. Hast du irgendwelche Zahlen/Richtwerte für mich? Wenn ich das prüfen würde, hätte ich eine Zahl ohne Bezug.

- aehm nein 🙂 der semantische ersetzt nicht den technischen sondern ist ein zusätzlicher der aber nicht zwingend erforderlich ist ;)

- wie genau meinst du das mit dem Ersetzen, in Bezug auf die SIDs?

- Nein habe ich nicht. Muss mal wenn ich im Büro bin (kann ein oder zwei Wochen dauern) schauen ob ich irgendwo etwas in meinen Unterlagen stehen habe. Aber ich bin auch der Meinung das man keine feste Anzahl brauch, sondern eher der Verwendungszweck und die Datenquelle hauptsächlich entscheidend ist.

Grüße

- wofür dann der semantische Schlüssel ist, verstehe ich immer noch nicht :-)  aber wenn man ihn nicht angeben brauch, solls mir egal sein ^^

-  ein Beispiel was ich meine mit höheren Datenvolumen durch schreibopt. DSO wäre:

Datenfluss Lösung 1:
DataSource => drei standard DSO´s => drei InfoCubes

Datenfluss Lösung 2:
DataSource => einen schreibopt. DSO => drei standard DSO´s => drei InfoCubes

Auf diese Weise habe ich einen schreibopt. DSO zusätzlich eingefügt. In den Beispielen die ich bisher gesehen habe, stellen schreibopt. DSO´s immer eine zusäzlich Ebene dar und ersetzen keine anderen standard DSO´s oder Cubes.

Was für mich jetzt interessant ist, ob sich wie im Beispiel Lösung 2 das Daetnvolumen stark erhöht. Wenn ich als Beispiel durch ein schreibopt. DSO ein 40 % höheres Datenvolumen hätte, stellt sich die Frage, ob es dem Nutzen überhaupt rechtfertigt ist.

Warum gibt es den semant. Schlüssel?

- Im Kontext des schreiboptimierten DSO hat der semant. Schlüssel eher informativen Charakter.

- Je nach Einstellung der Eigenschaften des schreibopt. DSOs kann es allerdings erzwungen werden, dass ein Fehler ("rote Ampel") vom DTP ausgegeben wird, wenn zum gleichen semant. Schlüssel ein neuer Satz kommt.

- Außerdem ist der Vorteil, dass man beim (Zurück-)Umschalten auf Typ Standard-DSO den semant. Schlüssel beibehält. Ein Umschalten ist jedoch nur möglich solange keine Daten im DSO sind.

Natürlich braucht ein DSO auch DB-Platz. Aber (wie die PSA) kann man das schreibopt. DSO in "Lösung 2" auch nach jedem Füllen wieder leeren, und dadurch ist der Speicherbedarf nicht größer als ein Laderequest groß ist, was wohl verglichen mit dem Gesamtvolumen des BW (Historie von 1000en von Ladeprozessen im ChangeLog) eher nicht ins Gewicht fällt.

Der große Vorteil ist, dass man, basierend auf bereits harmonisierten Daten ein Kriterium für die Parallelisierung beim Laden entwickeln kann und damit die Ladeperformance steigern. Dies ist z. B. notwendig, wenn die Nacht nicht reicht, um alle Daten sequentiell zu laden.

Es gibt auch Szenarios, die ein Standard-DSO wirklich durch ein schreiboptimiertes ersetzen, z. B. wenn sichergestellt ist,dass jeder semant. Schlüssel eindeutig ist. Denn dann würde die Aktivierung die Daten nur 1:1 in die Aktiven Daten kopieren und nochmal ins Changelog -> also unnötig verdoppeln.

viele Grüße

alex