# DAP Fragenkatalog

## GIS

> 1. Nennen Sie klassische Anwendungsfälle für Geoinformationssysteme.

- Öffentliche Verwaltung
- Verkehrsnetze, Reiseauskunft der Bahn
- Umweltplanung
- Marktanalysen

> 2. Warum es nicht optimal, räumliche Daten in klassisch relationalen Datenbanksystemen zu verwalten?

- Nur elementare Datentypen
- Sehr komplexe Queries durch Joins
- Hat man lediglich Stützpunkte in einer relationalen Datenbank, sind Charakteristika wie Linienzüge oder Polygone gar nicht explizit bekannt. Die Queries müssten diese stets ermitteln.
- Funktionen mit Raumbezug müssen selbst implementiert werden, entweder auf der Datenbank oder auf der Anwendungsebene -> Fehleranfällig und nicht performant

> 3. Was ist ein Thema?

Die Zusammenfassung von geographischen Objekten mit gleichen fachlichen Attributen.

> 4. Geben Sie drei Beispiele für Themen.

- Straßennamen
- Landnutzung
- Bevölkerungsdichte

> 5. Welche Operationen gibt es auf Themen? (8) Geben Sie auch ein Beispiel.

- Projektion
- Gegeben: Karte mit Straßennamen und Flüssen.
- Ergebnis: Ausblenden der Flüsse, Fokus auf Straßennamen
- Selektion
- Gegeben: Karte von Hannover mit eingeteilten Distrikten und Postleitzahlen.
- Ergebnis: Nur Disktrikte anzeigen, die eine PLZ > 30457 haben. Alle anderen Distrikte werden ausgeblendet.
- Union
- Gegeben: Tabelle mit Gebäuden und Tabelle mit Straßen, beide jeweils mit dem Attribut Postleitzahl
- Ergebnis: Gebäude und Straßen über das Attribut PLZ vereinigen
- Overlay
- Gegeben: Tabellen zu Straßen und Landnutzung
- Ergebnis: Räumlicher Join von Straßen und Flächen
- Point Query / Windowing / Clipping
- Gegeben: Tabelle mit Gebäuden, Adressen und räumlichen Informationen
- Ergebnis: Alle Bewohner im Umkreis von 300 Metern sollen wg. Bombenentschärfung evakuiert werden.
- Point Query sicherlich geeigneter, jedoch ginge Clipping und Windowing sicherlich auch
- Merging
- Gegeben: Zwei Themen "Fußgängerwege" und "Radfahrwege"
- Ergebnis: Neues Thema, "Autofreie Straßen"

> 6. Was unterscheidet die Themenoperationen Selection und Windowing?

Bei der Selection basiert das Suchkriterium auf fachlichen Attributen, während beim Windowing ausschließlich basierend auf räumlichen Informationen selektiert wird.

> 7. Was unterscheidet die Union-Operation in Geoinformationssystemen vom klassisch relationalen Modell?

In der räumlichen Vereinigung sind auch Objekte Teil der Ergebnismenge, dessen Attribute nur in einem der beiden Themen vorkommen. In der relationalen Algebra ist dies nicht möglich.

> 8. Was unterscheidet Windowing von Clipping?

Die Objekte werden nach den gleichen Kriterien selektiert, nur erhält man beim Windowing die vollständigen Objekte, inkl. der Teile, die außerhalb der Bounding Box liegen. Clipping liefert ausschließlich die Teile der räumlichen Objekte zurück, die innerhalb der Bounding Box liegen.

> 9. Übung: Man will alle Ways ermitteln, die im 100 Meter - Umkreis zu einem Query Point liegen. Man besitzt lediglich die Koordinaten der Stützpunkte. In welchen Fällen ist es nicht ausreichend, die Distanz zu allen Stützpunkten und dem Query Point zu ermitteln und auf dieser Basis die entsprechenden Ways zurückzuliefern?


Diese Art von Query würde in diesem Beispiel nicht das gewünschte Objekt zurückliefern, welches durch den schwarzen Linienzug dargestellt wird. Die Distanz zum Linienzug beträgt lediglich fünf Meter, jedoch vergleicht die Query stets nur die Distanz zu den Stützpunkten A und B, die weiter als 100 Meter entfernt liegen.

> 10. Übung: Wie kann man die Abfragen in dem klassisch relationalen Modell, das lediglich Stützpunkte enthält, optimieren?

Einmalig im Vorfeld Tabelle anlegen, das zu jedem Way eine minimale Bounding Box beinhaltet. Einfachster Fall:

|WayId|MinLat|MinLon|MaxLat|MaxLon|
|---|---|---|---|---|
|||||

Liegt die Bounding Box nicht innerhalb der Suchdistanz, gilt dies auch für das eingeschlossene Objekt. Die Operationen sind recht einfach, da nur Fließkomma-Zahlen verglichen werden.

> 11. Was sind Anforderungen an eine Relationale Datenbank mit räumlicher Erweiterung?

- Definition von räumlichen Datentypen wie Punkt, Linienzug, Kreis, Polygon, ...
- Abfragesprache sollte erweitert werden um Funktionen wie ``intersects(objectA, objectB)`` oder ``isPolygon(arrayOfLines)``
- Datenspeicherung, Zugriff und Queries sollte effizient sein

> 12. Geben Sie ein 9-Intersection-Model zu dieser Beziehung an:


:ballot_box_with_check: Verifizierte Lösung

$\begin{bmatrix}T & T & T \\F & F & T \\ F & F & T\end{bmatrix}$

> 13. Geben Sie ein 9-Intersection-Model zu dieser Beziehung an:


:ballot_box_with_check: Verifizierte Lösung

$\begin{bmatrix}F & F & T \\F & T & T \\ T & T & T\end{bmatrix}$

> 14. Geben Sie ein 9-Intersection-Model zu dieser Beziehung an:


$\begin{bmatrix}F & F & T \\F & F & T \\ T & T & T\end{bmatrix}$

:ballot_box_with_check: Verifizierte Lösung

> 15. Geben Sie ein 9-Intersection-Model zu dieser Beziehung an:


$\begin{bmatrix}T & T & T \\F & T & T \\ F & F & T\end{bmatrix}$

:warning: Nicht verifiziert!

> 16. Geben Sie ein 9-Intersection-Model zu dieser Beziehung an:


$\begin{bmatrix}T & T & T \\T & T & T \\ T & T & T\end{bmatrix}$

:warning: Nicht verifiziert!

> 17. Geben Sie ein 9-Intersection-Model zu dieser Beziehung an:

$\begin{bmatrix}T & T & T \\T & F & T \\ T & T & T\end{bmatrix}$

:warning: Nicht verifiziert!

> 18. Geben Sie ein 9-Intersection-Model zu dieser Beziehung an:


$\begin{bmatrix}T & F & F \\F & T & F \\ F & F & T\end{bmatrix}$

:warning: Nicht verifiziert!

> 19. Geben Sie ein 9-Intersection-Model zu dieser Beziehung an:


$\begin{bmatrix}F & F & T \\T & T & T \\ F & F & T\end{bmatrix}$

:warning: Nicht verifiziert!

> 20. Operationen wie ``overlaps(Geometry g): Geometry[]`` sind komplex. Warum ist das so? Wie könnte man dies beschleunigen?

Müsste man alle Geometrien aus dem Suchraum mit der Geometrie ``g`` auf die Overlaps-Beziehung prüfen, wäre das extrem inperformant.

Eventuell müsste man viel zu viele Geometrien prüfen, die sowieso nicht überlappen. Zudem sind Operationen dieser Art die Komplexität $O(n^2)$ oder $O(n*log(n))$, wobei n hier die Anzahl der Stützpunkte der Geometrie darstellt.

Idee: Bounding Box jeder Geometrie zusätzlich speichern und damit erstmal Vorfilterung möglicher Objekte vornehmen, die überlappen könnten. Die Vorfilterung ist nicht perfekt, schließt aber direkt sehr viele Kandidaten aus. Zudem ist der Vergleich zweier Bounding-Boxen immer konstant aufwendig, egal wie komplex das Polygon ist.

> 21. Übung: Welche Themen kann man mithilfe der OSM-Daten beschreiben?

1. Straßen: Autobahnen, Straßenname, Fußweg, Fahrradweg, Tempolimits...
2. Gebäude: Name, Adresse, Höhe, ...
3. Landnutzung: Gruppierung von Flächen gemäß Wald, Landwirtschaft, Einzelhandel, ...

> 22. Was ist das Spaghetti-Modell?

tbd

> 23. Was ist das Netzwerk-Modell?

tbd

> 24. Was ist das topologische Modell?

tbd

> 25. Zerlegen Sie diese Welt in ihre topologischen Primitive!


> 26. Betrachten Sie die abgebildete Grafik und die Beispiele P1, R1 und S4.
> Wie ist die Beziehung zwischen den topologischen Primitiven und den Realwelt-Objekten (N:1, 1:N, N:M)? Welche anderen Kardinalitäten wären möglich, und wie?


Zu einem Real-Welt-Objekt gehören möglicherweise mehrere topologische Primitive, so ist es in der Grafik.

Es wäre auch möglich, dass eine N:M-Beziehung vorliegt. Die Kanten E9, E10 und E11 könnten zu einem Weg, aber auch zu einem Grundstück gehören.

> 27. Was sind Nachteile des topologischen Modells?

Es kann kompliziert sein, neue Features in das Modell einzufügen. Fügt man ein Objekt in ein bestehendes Objekt ein, muss dieses unter Umständen gänzlich neu strukturiert werden.


> 28. Warum benötigt man räumliche Index-Strukturen?

- Geometrische Algorithmen sind relativ aufwendig und kaum bis gar nicht zu optimieren
- Der einzig effiziente Weg ist, die Anzahl der Objekte, auf die man den Algorithmus anwendet, zu reduzieren

> 29. Warum kann man keinen Standard-Index benutzen?

Datenbanken arbeiten typischerweise mit einem $B^{+}$ - Baum, der sich nur für Datentypen mit einer linearen Ordnung eignet. Bounding Boxes bestehen aus vier Fließkomma-Zahlen, weshalb dies nicht mehr funktioniert.

> 31. Beschreiben Sie die Idee sowie grundlegende Eigenschaften von R-Bäumen.

tbd

> 32. Welche Laufzeit haben R-Bäume, und woran liegt das?

- Die Laufzeit von R-Bäumen liegt in $O(n*log(n))$.
- Logarithmisch daher, weil sich die Baum-Höhe logarithmisch zur Anzahl der Elemente verhält.
- Faktor $n$, da ein Query Point P in mehreren Knoten enthalten sein kann.

> 33. Geben Sie Pseudo-Code für eine Punkt-Abfrage an!

tbd

> 34. Geben Sie Pseudo-Code für das Einfügen eines neuen Objektes in den R-Baum an!

tbd

> 35. Geben Sie stichpunkt-artig an, wie die Punkt-Abfrage für $P$ ablaufen würde.


tbd

> 36. Wie könnte das Löschen in R-Bäumen aussehen?

- Suche Objekt im Baum, ähnlich wie bei Point Query
- Knoten entfernen
- Baum bereinigen, beginnend beim Blatt bis hoch zur Wurzel nach folgendem Schema
- Hat der aktuelle Knoten immer noch zwischen $M/2$ und $M$ Elemente, muss nur das Verzeichnisrechteck aktualisiert werden.
- Hat der Knoten einen Unterlauf, wird der Knoten entfernt. Die Objekte, die zum entfernten Knoten gehören, fügt man zur Menge Q hinzu.
- Die beschriebene Bereinigung wird **für jeden Knoten** rekursiv, bottom up vom Blatt zur Wurzel, durchgeführt. Die in die Menge Q aufgenommenen Objekte werden dann neu in den Knoten eingefügt, gemäß der bekannten Algorithmen zum Einfügen von Objekten in den Baum.

> 37. Welche Stategien gibt es beim Einfügen von R-Bäumen?

- Wenn mehrere Knoten das Objekt beinhalten: Wähle den Knoten mit der kleinsten Fläche.
- Es existiert genau ein Knoten für das Objekt: Füge das Objekt dort ein.
- Es existiert kein Knoten für das Objekt: Wähle den Knoten, den man am wenigsten expandieren müsste.

> 38. Welche Stategien gibt es zur Aufteilung von überlaufenden Knoten?

tbd

> 39. Welche räumlichen Zugriffsmethoden existieren in Oracle Spatial?

Oracle bietet R*-Baum an. Dieser wird ähnlich wie ein gewöhnlicher Index angelegt. Der Index-Typ `MDSYS.SPATIAL_INDEX` muss angegeben werden.

> 40. Welche räumlichen Zugriffsmethoden existieren in MongoDB?

MongoDB implementiert räumliche Indexstrukturen gemäß raumbasiertem Ansatz. Raum wird in kleine Rechtecke unterteilt. Man merkt sich, in welchem Bereich die Objekte liegen.

> 41. Beschreibe pseudocode-artig 3 räumliche SQL-Funktionen (Funktionsname, Argumente), dessen Rückgabetyp ein Skalar ist.

- sdo_geom.area(geom): float
- sdo_geom.distance(geomA, geomB, unit): float
- sdo_geom.length(geom): float

> 42. Beschreibe pseudocode-artig 3 räumliche SQL-Funktionen (Funktionsname, Argumente), dessen Rückgabetyp ein bool'scher Wert ist.

- sdo_geom.within_distance(geomA, geomB, dist): bool
- sdo_geom.relate(geomA, geomB, relationType): bool
- sdo_geom.nn(geomA, geomB, nnCount): bool

> 43. Beschreibe pseudocode-artig 5 räumliche SQL-Funktionen (Funktionsname, Argumente), dessen Rückgabetyp eine Geometrie ist.

- sdo_geom.mbr(geom): Rectangle
- sdo_geom.mbc(geom): Circle
- sdo_geom.aggr_mbr(geom): Rectangle `/* MBR aller Geometrien eines Themas */`
- sdo_geom.centroid(geom): Point
- sdo_geom.aggr_union(geom): Geometry `/* Vereinigtes Polygon über alle Geometrien eines Themas */`

> 44. Geben Sie eine beispielhafte SQL-Abfrage für eine Selektion an.

create view multiLaneStreets as (SELECT * FROM streets s WHERE s.lane_count > 1);

> 45. Geben Sie eine beispielhafte SQL-Abfrage für eine Projektion an.

create view multiLaneStreetNames as (SELECT id, name FROM multiLaneStreets s);

> 46. Geben Sie eine beispielhafte SQL-Abfrage für eine Union an.

create view residentalAndBuildings as (
(SELECT id, name, postalCode, maxSpeed
FROM landuse l
WHERE l.usage = 'residential')
UNION
(SELECT id, name, postalCode, NULL as maxSpeed)
FROM buildings b
WHERE b.name IS NOT NULL);
);

> 47. Geben Sie eine beispielhafte SQL-Abfrage für eine Window-/Point-Query an.

select b.id, b.name, distance(b.geom, queryPoint)
from buildings b
where sdo_nn(b.geom, queryPoint, 'num=20') = 'TRUE';

> 48. Geben Sie eine beispielhafte SQL-Abfrage für Clipping an.

Auf SQL-Ebene schwierig, vermutlich.

> 49. Geben Sie eine beispielhafte SQL-Abfrage für Merging an.

/* Erzeugt ein Polygon aus den Einzel-Polygonen jedes PLZ-Distriktes aus Hannover */
select sdo_aggr_union(p.geom)
from postalCodeDisticts p
where p.city = 'Hannover';

> 50. Geben Sie eine beispielhafte SQL-Abfrage für ein Theme Overlay an.

select ri.river_id, ri.river_name, ra.railway_id
from rivers ri, railways ra
where sdo_relate(ri.geom, ra.geom, 'intersect') = 'TRUE';

## IR

> 51. Skizzieren Sie die Architektur eines Information Retrieval Systems!

> 52. Zeigen Sie anhand von Beispielen vier linguistische Probleme, mit denen dokumentenbasierte IR-Systeme umgehen können müssen.

> 53. Was ist die Idee hinter dem bool'schen Modell, warum ist dies nicht ausreichend?

Alle Dokumente, die den Suchkriterien genügen, werden zurückgeliefert. Die Ergebnismenge ist unsortiert und obliegt keiner Rangfolge.

> 54. Berechne $f(d,q)$ mithilfe des a) Skalarproduktes und b) mithilfe des normierten Skalarproduktes. Wie ist der Unterschied zwischen a) und b) zu deuten?


> 55. Was ist die Idee hinter der Term-Häufigkeit $tf_{d,t}$? Wo liegen Grenzen dieser Metrik?

- Es soll berücksichtigt / gewichtet werden, wie spezifisch bestimmte Terme eines Dokuments sind bzw. wie häufig sie vorkommen. Kommt also ein Begriff häufiger vor, soll dies höher gewichtet werden.
- Dies führt nicht unbedingt zu optimalen Ergebnissen. Beispiel: Dokument enthält häufig den Term "campaign", obwohl es sich um eine Menschenrechtskampagne handelt, während die Query sich um Präsidentschaftskampagnen handelt.

> 56. Was ist die Idee hinter der inversen Dokumenten-Häufigkeit? Wie kann man diese berechnen? Geben Sie die Formel an und begründen Sie, warum sie sich so zusammensetzt.

> 57. Warum wird der Logarithmus in der inversen Dokumenten-Häufigkeit verwendet?

- Beispiel: 1000 Dokumente. Ein Dokument, das einmal vorkommt, erhält das Gewicht 1000. Ein Dokument, das zweimal vorkommt, erhält das Gewicht 500. Der Faktor 2 für diese Gewichte ist äußerst unverhältnismäßig.
- Mit dem Logarithmus kann man diese Unverhältnismäßigkeiten abschwächen.
- Mit dem Logarithmus kann man den Wertebereich stark eindämmen -> Handlichere Zahlen, ohne das Ranking zu ändern.
- Der Logarithmus von 1 ist 0. Somit werden Terme, die in jedem Dokument vorkommen, gar nicht gewichtet.

> 58. Gegeben folgendes Beispiel und die inversen Dokumenten-Häufigkeiten $news = 1.5, about = 1.0, presidential = 2.5$, $campaign = 3.5, organic = 3.6, food = 2.3, of = 0.9$. Berechne $f(d,q) basierend auf der inversen Dokumenten-Häufigkeit.


> 59. Angenommen, ein seltener Begriff kommt sehr häufig im Dokument vor, dann liegt es nahe, dass das Ranking auch sehr hoch ist. Passt dies semantisch aber nicht zur Query, muss man diesem Ungleichgewicht entgegenwirken. Beschreiben Sie drei Möglichkeiten, dies zu erreichen.

> 60. Erklären Sie die BM25-Transformation zur Anpassung der Term-Häufigkeit. Wie wirkt sich die Wahl des Faktors $k$ aus? Welche Alternative gibt es, wo liegt hierbei der Unterschied?

> 61. Aus welchen Komponenten besteht die Okapi-Formel?

> 62. Betrachten Sie die Formel für die Query Likelyhood - wo genau stecken dort die Metriken/Komponenten Termhäufigkeit, inverse Dokumentenhäufigkeit und Dokumentlänge drin?

## DWH

> 63. Was ist ein Data Warehouse?
> 64. Was ist ein Data Lake?
> 65. Was ist ein Data Mart?
> 66. Was ist ein BI-System?
> 67. Was sind Unterschiede zwischen OLTP-Datenbanken und DWHs?
> 68. Skizzieren Sie die grundlegende DWH-Architektur!
> 69. Nennen Sie Anwendergruppen und Schlüsselaspekte von DWHs!
> 70. Was ist der Unterschied zwischen MOLAP und ROLAP?
> 71. Was unterscheidet ein Star-Schema von einem Snowflake-Schema?

* Das Star-Schema ist im Gegensatz zum Snowflake-Schema nicht in der 3NF modelliert.
* Im Star-Schema kommt man daher mit deutlich weniger Joins aus, was für eine gute Performance sorgt.
* Star-Schema ist übersichtlicher.

> 71. Nennen und erklären Sie drei Typen von Faktentabellen!

* Transaction Fact Grain
* Periodic Snapshot Fact Grain
* Acumulation Snapshot Fact Grain

> 72. Was ist der Unterschied zwischen additiven, semi-additiven und nicht-additiven Fakten? Geben Sie Beispiele an!

* Es geht um die Aggregierbarkeit von Attributen.
* Additive Fakten lassen sich nach jeder Dimension aggregieren, bspw. Umsatz.
* Semi-additive Fakten lassen sich manchen Dimensionen aggregieren, nicht aber nicht nach jeder. Beispiel: Verkaufte Stückzahl
* Nicht-additive Fakten lassen sich nach keiner Dimension sinnvoll aggregieren. Beispiel: Stückpreis (hat ohne Verkaufsmenge keinen Mehrwert)

> 73. Nennen und erläutern Sie multidimensionalen OLAP-Operationen!

> 75. Erklären Sie das Konzept von multidimensionalen Daten. Was sind Indikatoren, Dimensionen und Hierarchien?

> 76. Was ist ein Stern Schema und was sind dessen Merkmale?

Daten sind nicht normalisiert, es gibt Dimensionstabellen und Faktentabellen. Die Dimensionstabellen enthalten auch Hierarchiestufen. Redundanzen sind ok.

> 77. Was sind Surrogate Keys, warum werden sie benötigt und wo werden sie erzeugt?

- Ein sog. Surrogate Key ist ein künstlicehr Schlüssel, der als PK für die Dimension und FK für die Faktentabelle verwendet wird.
- So macht man sich unabhängig von fachlichen Schlüsseln und gewährleistet **referenzielle Integrität**.
- Dies gewährleistet referenzielle Integrität.
- Man macht sich unabhängig von fachlichen Schlüsseln.
- Surrogate Keys werden vom ETL-Tool oder von der Ziel-Datenbank erstellt (z.B. Oracle Sequence)

> 78. Weisen Sie dieser beispielhaften SQL-Query die mehrdimensionalen OLAP-Operationen zu:
> ```sql
> select dim_attribute, sum(measure)
> from fact_table f
> join dim_table d on d.key = f.key
> where ...
> group by dim_attribute;
> ```

tbd

> 79. Schreiben Sie eine SQL-Query zu folgendem Sachverhalt: Gesucht sind die Produktgruppen, die im Jahr 2010 im Bezug auf den Umsatz am relevantesten waren.

select p.product_group, sum(f.revenue)
from fact_revenue f
join dim_product p on p.product_key = f.product_key
join dim_date d on d.date_key = f.date_key
where d.year = "2010"
group by p.product_group
order by sum(f.revenue)

> 80. Was sind Slowly Changing Dimensions?

> 81. Wann spricht man von SCP Typ 1 bzw. SCD Typ 2?

> 82. Was ist ein Head Key?

> 83. Geben Sie ein Beispiel anhand einer Tabelle für SCD Typ 2.

> 84. Aus Alt-Klausur: Man sollte sein eigenes Bankkto mit Überweisungen verwalten, Lastschrift oder Überweing (Type sollte unterschieden werden), Recipients/Sender haben Namen, Überweisungen haben Kategorien, die aus Obergruppen und Namen bestehen. Historisierung sollte nicht beachtet werden. Dazu Star-Schema aufstellen.

table DimCustomer
    customer_key: integer (PK)
    customer_name: varchar(100)

table DimTransfer
    transfer_key: integer (PK)
    transfer_type: varchar(100) -- Lastschrift/Überweisung
    transfer_category_name: varchar(100)
    transfer_category_group: varchar(100)

table DimDate
    date_key: integer (PK)
    date_raw: DateTime
    date_year: integer
    date_month: integer
    date_day: integer
    date_hour: integer
    date_minute: integer
    date_seconds: integer
    date_week_day: integer
    
table FactTransaction
    transaction_key: integer (PK),
    recipient_key: integer (FK->DimAccount)
    sender_key: integer (FK->DimAccount)
    transfer_key: integer (FK->DimTransfer)
    date_key: integer (FK->DimDate)
    transaction_amount: double

> 85. Recipient sollte IBAN und Account bekommen, welcher sich ändern kann. Dabei soll Historisierung beachtet werden!

table DimCustomer
    customer_key: integer (PK)
    head_key: integer
    customer_name: varchar(100)
    customer_iban: varchar(100)
    customer_bank_name: varchar(100)
    valid_from: date (not nullable)
    valid_to: date (nullable)

> 86. Schreibe SQL: Alle Überweisungen die zur Sparkasse Hannover im Jahr 2018 gingen. (ek: Ich denke mal hier fehlt der summierte Betrag.)

select re.customer_bank_name, sum(f.transaction_amount)
from FactTransaction f
join DimDate d on f.date_key = d.date_key
join DimCustomer re on re.customer_key = f.recipient_key
join DimTransfer t on t.transfer_key = f.transfer_key
where t.transfer_type = "Überweisung" and d.date_year = 2018 and re.customer_bank_name = "Sparkasse Hannover"
group by re.customer_bank_name

> 86. Wie werden Fakten im ETL-Prozess geladen, im Hinblick auf Foreign Keys aus den Quellsystemen? Welche Probleme können dabei auftreten?

- Datensatz, der aus der Quelle kommt, wird schrittweise bearbeitet. Jede fachliche ID (bspw. Customer-ID) wird durch den entsprechenden Surrogate Key der Dimension (bspw. DimCustomer) ersetzt.
- Dazu muss es eine Zuordnung zwischen Surrogate Keys und den fachlichen Schlüsseln aus der Quelle geben. Häufig ist diese Art von Map die Dimensionstabelle selbst, da dort sowohl SK als auch fachliche ID gespeichert sind.
- Probleme:
- Es kann zur fachlichen ID kein SK zugeordnet werden.
- Es kann zu Kollisionen kommen, bspw. wenn der PK der resultierenden Tabelle ein zusammengesetzter PK ist.
- Lösung:
- Fehlerfälle zurücksetzen und ggf. in eine Fehler-Tabelle auslagern, um sie am Ende nochmal zu behandeln.

ggf. ergänzen!

> 87. Welche zwei Typen von Ladevorgängen gibt es im ETL-Prozess?

Initialer Load

Periodischer Load

Erklärung tbd

> 88. Welche Arten zur Detektion von Änderungen im ETL-Prozess gibt es?

1. Zeitstempel
2. Full Diff Compare
3. Database Log Scraping

Erklärung tbd

> 89. Skizzieren Sie einen klassischen Ablauf zum Management von Slowly Changing Dimensions.


- Vergleich von Quellen und Dimensionen im DWH
- Drei Fälle möglich
- Quelle/Dimension stimmen überein - Ignorieren
- Daten sind neu - Surrogate Key zuweisen, Zeitstempel setzen, in DB einfügen
- Felder geändert
- SCD T1 -> Felder überschreiben
- SCD T2 -> Surrogate Key zuweisen, Zeitstempel (valid from/to) setzen, danach Record updaten, der zuvor der aktuellste war

> 90. Skizzieren Sie eine Surrogate Key Pipeline!


> 91. Skizzieren Sie die Schichten eines DWHs und erklären Sie den Zweck jeder einzelnen Schicht.


- Staging Area
- Staging Area beinhaltet neue oder geänderte Daten aus den Quellen
- Entkoppelt ETL-Prozess von Quellen
- In einer Persistent Stage Area wird ein 1:1-Abbild der Quellen erzeugt
- Noch nichts integriert, (fast) genau das Schema der Quellen
- In der Übung etwas anders -> Hier wurde die Stage Tabelle für Artikel schon aggregiert, aus Mitgliedschaften, Merchandise und Tagespässen.
- Wenn man die Kapazitäten hat, ist eine Persistent Staging Area vorteilhaft
- gut für Fehlersuche
- Full Diff Compare möglich
- Persistent Staging Area kann Data Lake Charakter haben -> es stehen Informationen bereit, mit denen man neue Features einführen könnte

- Integration Layer
- beinhaltet Ergebnisse der transformierten Daten
- Konsolidierung und Cleansing (Bereinigung, Harmonisierung)
- meist nicht-persistent, manchmal aber doch persistent. nennt man dann Operational Data Store (ODS)

- History Layer
- sammelt historische Versionen der Daten
- häufig normalisiert (3NF)
- nicht optimal für spezielle Herausforderungen (was heißt das?)
- oft persistent

- Data Provisioning Layer
- beinhaltet multidimensionale Daten für Reports und Analysen
- entweder relational (Star/Snowflake) oder als multidimensionale Datenbank (MDBMS)
- MOLAP-Datenbereitstellung:
- persistente MDBMS
- gefüttert durch persistente History Layer
- neu bauen kompliziert
- ROLAP-Datenbereitstellung:
- Star Schemata
- Keine Persistenz in History Layer erforderlich

> 92. Welche 4 Architekturstile gibt es im DWH-Umfeld? Was sind dessen Eigenschaften, Vor- und Nachteile?

- Central DWH
- Zentrales DWH (auch Enterprise DWH) über gesamten Konzern
- Single Point Of Truth (+)
- sehr schwierig, alle Bedürfnisse unter einen Hut zu bekommen

- Independent Data Marts
- Ein DWH pro Unternehmensbereich, aber ggf. Überschneidungen in Quell-Datenbanken
- mehr Freiheit pro Unternehmensbereich (+)
- Kann Inkonsistenzen hervorrufen bzw. beinhalten

- Hub-and-Spoke-Architektur
- Bereichsspezifische Data Marts, aber shared DWH-Architektur von den Quellen bis einschließlich hoch zur History Layer
- nichtsdestotrotz ist die Umsetzung der shared DWH-Architektur schon äußerst komplex

- Data Mart Bus Architektur
- Jeder Unternehmensbereich hat sein eigenes, isoliertes DWH.
- Zugriff auf Data Provisioning Layers der anderen DWHs jedoch möglich.
- Dimension, die schon in anderem DWH existiert, wird von dort aus kopiert.
- --> Jeder ist unabhängig, aber Doppelarbeit wird durch Koordination vermieden.

## DQ

> 93. Wo werden Daten typischerweise korrigiert? In den Quellen, im DWH?

- Datenqualitätsfehler fallen nach Kimball in die Kategorie A, B, C und D
- Immer geprägt von Konflikten
- Kategorie A -> MUSS in den Quellen behoben werden
- Kategorie B -> SOLLTE in den Quellen behoben werden
- Kategorie C -> SOLLTE im ETL-Prozess behoben werden
- Kategorie D -> MUSS im ETL-Prozess behoben werden