Anhand einer LSA++ Architektur möchte ich nun anhand eines Beispieles die LSA++ Layer analysieren und erklären, ob diese persistent oder virtuell sind.
Unter Bezugnahme auf meinen ausführlichen Artikel dazu, möchte ich nochmals die wichtigsten Punkte wiederholen.
Hier ein Beispiel für die Architektur der Sales Order:
Schauen wir uns weiter noch die zentralen BW-Objekte an:
| BW-Objekt | Beschreibung | Modellierungseigenschaften | Langbeschreibung |
| Quellsystem | Quelle der Daten | Quellsystemtyp, Datenformat, Metadaten | Ein logischer Name für ein System, eine Anwendung, eine Datenbank oder eine Dateiverbindung, auf die vom BW-System aus zugegriffen werden kann. |
| DataSource | Strukturdefinition zum Extrahieren von Daten | Schlüsselfelder, abhängige Felder, Filteroptionen, Delta-Mechanismus | Eine Strukturdefinition zum Extrahieren von Daten aus einem Quellsystem. |
| InfoProvider | Datenmodellierungsobjekt | Navigationsoptionen, verfügbare Felder oder InfoObjects, Schlüssel- und abhängige Felder, Part Provider und Feldzuordnungen | InfoProvider (einschließlich InfoObjects) sind die wichtigsten Datenmodellierungsobjekte von SAP BW. Sie stellen die Objekte dar, die die Daten des Quellsystems in einen sinnvollen Geschäftskontext bringen und stellen diese Daten für Queries und Reporting-Tools bereit. Queries werden auf InfoProvidern definiert. |
| Transformation | Gruppe von Transformationsregeln | Aggregation von Kennzahlen, Feldzuordnungen, Formeln, Konvertierungen (Einheiten, Währungen), Routinen | Eine Gruppe von Transformationsregeln, die zum Bereinigen und Aufbereiten von Daten beim Laden der Daten zwischen zwei physischen Datenzielen innerhalb einer oder zwischen zwei LSA++-Schichten verwendet werden. |
| InfoSource | Logische Struktur zum Kombinieren von Daten | Verfügbare Felder oder InfoObjects, optional: Felder als Schlüsselfelder festlegen | Eine logische Struktur, die das Kombinieren von Daten ohne physischen Speicher ermöglicht. Auf diese Weise können mehrere Transformationen verwendet und kombiniert werden, um komplexe Transformationsregeln zu erstellen, ohne dass die Zwischenergebnisse in einem physischen Speicher gespeichert werden müssen. |
| Datentransferprozess | Definition eines Datenladeprozesses | Extraktionsmodus (Full oder Delta), Filtereinstellungen, Semantische Gruppen, Performanz- und Fehlerbehebungseinstellungen | Eine Definition eines Datenladeprozesses zwischen zwei physischen Objekten des SAP BW. Bei Ausführung wendet er die Transformationsregeln an, die zwischen diesen Objekten definiert sind. |
| Datenfluss | Objektgruppe, die zum Laden von Daten verwendet wird | ||
| Query | Definition einer Datenauswahl | Zeilen/Spalten Drill-Down, Anzeigeeigenschaften, Formeln, Filterdefinitionen (fix oder variabel) | Eine vordefinierte mehrdimensionale Definition einer Datenauswahl. Sie fordert Daten von einem InfoProvider an und stellt die aus dem InfoProvider ausgewählten Daten Reporting- und Analysetools zur Verfügung. Queries werden auf InfoProvidern definiert. |
Weiters noch interessant ist hierfür:
Sehen wir uns das anhand eines konkreten Beispiels an:
- Ganz oben finden wir einen Composite Provider (/IMO/V_SD10) der der Virtual Data Mart Schicht zugeordnet ist und somit virtuell ist.
- Dieser wird von ADSOs gespeist (/IMO/D_SD20, /IMO/D_SD31, /IMO/D_SD30, /IMO/D_SD11, /IMO/D_SD10, /IMO/D_SD16, /IMO/D_SD21) diese sind persistiert und sind Bestandteil des Flexiblen EDW Core (Integrated DWH Layer)
- Die ADSOs werden alle von InfoSources gespeist. Diese können sowohl virtuell als auch persistent sein. In der Regel sind sind diese virtuell (“Eine InfoSource ist eine logische Struktur, die das Kombinieren von Daten ohne physischen Speicher ermöglicht.”). Sie sind dem Integrated DWH Layer zugeordnet.
- Die InfoSources werden aus Daten des Corporate Memory Layers gespeist, welche in Form von ADSOs vorliegen und somit persistent sind.
- Den ADSOs vorgereit sind die Datenquellen, welche im Source System (A57C903ODP) persistiert sind.
