Übungsaufgaben zu Data Warehouse, ETL und Sternschema

https://bildung.social/@oerinformatik/

https://oer-informatik.de/data-warehouse-etl-uebungsaufgaben

Data Warehouse, Data Mart, Data Lake, ETL, ELT, Sternschema, Faktentabelle, Dimensionstabelle, Surrogatschlüssel, SQL, Übungsaufgaben, Prüfungsvorbereitung

tl/dr; (Bearbeitungszeit insgesamt 68 min, mehrere Aufgaben): Zwei Übungsaufgaben: Für einen Fahrrad-Onlineshop grenzt Du Data Warehouse, Data Mart und Data Lake ab, entwickelst aus einem Verkaufsexport ein Sternschema, legst die Faktentabelle mit SQL an, wertest sie aus und erläuterst anhand eines englischen Textes Surrogatschlüssel. Danach planst Du für die Veranstaltungen eines Berufskollegs die Zusammenführung von Check-in-, Sensor- und Anmeldedaten: zentrale oder dezentrale Speicherung, ETL-Schritte und Transformationen mit Datentypen, Datenschutz und ETL oder ELT. Alle Lösungen sind ausgeblendet und mit Punkteverteilung versehen [AI-Assisted]. (Zuletzt geändert am 27.10.2026)

Diese Übungsaufgaben gehören zum Artikel Data Warehouse, ETL und Sternschema: Daten für Auswertungen aufbereiten.

Hinweise zur Bearbeitung: Von FIDP wird erwartet, dass ihnen Aufgaben auf Profilkompetenz-Ebene (Aufgabe 3.1 und Aufgabe 3.2) keine Probleme bereiten. SQL-Anweisungen schreibst Du in MariaDB-Notation. Schreib Deine Lösung zuerst vollständig auf, bevor Du die Beispiellösung aufklappst.

Aufgabe 3.1: Ein Data Warehouse für den Fahrrad-Onlineshop (Profilkompetenz)

(ca. 36 min Bearbeitungszeit)

Du bist Auszubildende*r bei der CSB-Rad GmbH in Bielefeld, die Fahrräder und Komponenten in ihrem Onlineshop verkauft. Geschäftsführerin Sophie Bertram möchte regelmäßig auswerten, welche Warengruppen in welchen Monaten welchen Umsatz bringen und wie sich Privatkundschaft, Händler und öffentliche Auftraggeber unterscheiden. Bisher exportiert Geschäftsführer Cem Sarıkaya dafür Daten aus der Shop-Datenbank (MariaDB) in eine Tabellenkalkulation. Nun soll ein kleines Data Warehouse entstehen.

a) Beschreibe für Sophie Bertram die Begriffe Data Warehouse, Data Mart und Data Lake. (6 Punkte)

Data Warehouse: zentrale Datenbank, in der Daten aus mehreren Quellsystemen (Shop, Buchhaltung, Retourenliste …) über einen ETL-Prozess bereinigt, vereinheitlicht und in einer festen, für Auswertungen optimierten Struktur (z. B. Sternschema) dauerhaft und mit Historie gespeichert werden; die Daten werden geladen und gelesen, aber nicht mehr geändert.
Data Mart: Ausschnitt bzw. Kopie eines Teils des Data Warehouses, der für einen bestimmten Zweck oder eine Abteilung zusammengestellt ist, z. B. ein Data Mart „Vertrieb“ nur mit Verkaufsdaten.
Data Lake: Speicher für große Mengen Rohdaten aus verschiedenen Quellen in ihrem Originalformat (Tabellen, JSON, Logdateien, Bilder, Texte), meist nicht normalisiert und nicht bereinigt; eine Struktur wird erst beim Auslesen angewandt.

Je Begriff 2 Punkte.

b) Cem Sarıkaya fragt, warum die Auswertungen nicht einfach direkt mit SQL auf der Shop-Datenbank laufen können. Erläutere zwei Gründe. (4 Punkte)

Zwei der folgenden, jeweils erläutert:

Belastung des Shops: Auswertungen lesen sehr viele Datensätze und laufen lange. Auf der operativen Datenbank (OLTP) bremsen sie die gleichzeitigen Bestellungen der Kundschaft.
Fehlende Historie: In der Shop-Datenbank werden Werte überschrieben (aktueller Artikelpreis, neue Adresse). Ein Data Warehouse bewahrt die Stände und erlaubt Vergleiche über Jahre.
Mehrere Quellen: Zahlungen, Retouren oder Daten der Fertigungspartner liegen in anderen Systemen und lassen sich in der Shop-Datenbank nicht einfach verbinden.
Ungeeignetes Datenmodell: Die normalisierte Shop-Datenbank braucht für Auswertungen viele JOINs; ein Sternschema ist für Abfragen optimiert.

Je Grund 2 Punkte.

c) Cem Sarıkaya liefert einen Auszug aus dem bisherigen Export. Jede Zeile ist eine Bestellposition:

Auszug aus dem Verkaufsexport
bestellung_id	pos_nr	bestellt_am	kunde_id	kundentyp	plz	ort	land	artikelnr	bezeichnung	kategorie	oberkategorie	menge	einzelpreis_netto	rabatt_prozent	zahlungsart
1	2	2026-08-11 21:40:00	1	privat	33611	Bielefeld	DE	SCH-BUE-01	Bügelschloss, gleichschließend	Schlösser	Komponenten	2	62.18	0.0	Lastschrift
2	1	2026-08-20 10:12:00	2	privat	33615	Bielefeld	DE	RAD-EB-02	E-Bike „Kanal“ Mittelmotor 500 Wh	E-Bikes	Fahrräder	1	2436.13	0.0	Rechnung
3	2	2026-09-02 22:55:00	3	privat	33602	Bielefeld	DE	BRE-HYD-01	Hydraulische Scheibenbremse (Paar)	Bremsen	Komponenten	1	133.61	10.0	PayPal
4	1	2026-09-15 08:30:00	4	haendler	33649	Bielefeld	DE	RAD-CITY-01	Stadtrad „Promenade“ 7-Gang	Stadträder	Fahrräder	6	671.43	15.0	Rechnung
4	2	2026-09-15 08:30:00	4	haendler	33649	Bielefeld	DE	LIC-SET-01	Lichtset Nabendynamo StVZO	Beleuchtung	Komponenten	20	75.63	15.0	Rechnung

Die Faktentabelle fakt_verkauf ist bereits festgelegt; der Umsatz einer Position wird beim Laden als Menge × Einzelpreis × (1 − Rabatt) berechnet.

Vorgabe für das Sternschema: in der Mitte die vorgegebene Faktentabelle fakt_verkauf mit verkauf_id (PK), datum_key, kunde_key, artikel_key und zahlungsart_key (jeweils FK), bestellung_id, pos_nr, menge, rabatt_prozent und umsatz_netto; darum vier leere Tabellen zum Ausfüllen (mit KI erstellt)

Ergänze die Struktur der vier Dimensionstabellen mit Tabellennamen und Attributen aus dem Export. Kennzeichne Primär- und Fremdschlüssel, und trage die Beziehungen mit Kardinalitäten ein. (8 Punkte)

Sternschema mit fakt_verkauf in der Mitte und den Dimensionstabellen dim_datum (datum_key, datum, tag, monat, quartal, jahr, wochentag), dim_kunde (kunde_key, kunde_id als Business Key, kundentyp, plz, ort, land), dim_artikel (artikel_key, artikelnr als Business Key, bezeichnung, kategorie, oberkategorie) und dim_zahlungsart (zahlungsart_key, zahlungsart), jeweils 1:n zur Faktentabelle (mit KI erstellt)

dim_datum: aus bestellt_am abgeleitet; neben dem Datum werden Monat, Quartal, Jahr und Wochentag gespeichert, damit danach gruppiert werden kann. Eine Uhrzeit-Dimension ist möglich, aber nicht verlangt.
dim_kunde, dim_artikel: Die Shop-Schlüssel kunde_id und artikelnr bleiben als Business Key erhalten.
bestellung_id und pos_nr bleiben als degenerierte Dimension in der Faktentabelle.
Andere Notationen (z. B. Krähenfuß) und sinnvolle Abweichungen (z. B. Kundentyp oder Ort als eigene Dimension) werden anerkannt.

Bewertung: je Dimensionstabelle 1,5 Punkte (sinnvolle Attribute aus dem Export, Primärschlüssel), 2 Punkte für die Fremdschlüsselbeziehungen mit 1:n-Kardinalitäten.

d) Beschreibe, wie die Beziehungen zwischen der Faktentabelle und den Dimensionstabellen in einem Sternschema üblicherweise umgesetzt werden. (2 Punkte)

Jede Dimensionstabelle steht in einer 1:n-Beziehung zur Faktentabelle: Eine Dimensionszeile (z. B. ein Artikel) gehört zu vielen Faktenzeilen, jede Faktenzeile verweist auf genau eine Zeile jeder Dimension. Umgesetzt wird das, indem der Primärschlüssel der Dimension als Fremdschlüssel in der Faktentabelle steht.

e) Formuliere die SQL-Anweisung, mit der die Tabelle fakt_verkauf angelegt wird. Wähle passende Datentypen und lege die Fremdschlüssel auf die Dimensionstabellen aus Teilaufgabe c an (die Dimensionstabellen existieren bereits). (6 Punkte)

CREATE TABLE fakt_verkauf (
  verkauf_id      INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
  datum_key       INT UNSIGNED NOT NULL,
  kunde_key       INT UNSIGNED NOT NULL,
  artikel_key     INT UNSIGNED NOT NULL,
  zahlungsart_key TINYINT UNSIGNED NOT NULL,
  bestellung_id   INT UNSIGNED NOT NULL,
  pos_nr          TINYINT UNSIGNED NOT NULL,
  menge           SMALLINT UNSIGNED NOT NULL,
  rabatt_prozent  DECIMAL(4,1) NOT NULL DEFAULT 0.0,
  umsatz_netto    DECIMAL(10,2) NOT NULL,
  CONSTRAINT fk_fv_datum   FOREIGN KEY (datum_key)       REFERENCES dim_datum (datum_key),
  CONSTRAINT fk_fv_kunde   FOREIGN KEY (kunde_key)       REFERENCES dim_kunde (kunde_key),
  CONSTRAINT fk_fv_artikel FOREIGN KEY (artikel_key)     REFERENCES dim_artikel (artikel_key),
  CONSTRAINT fk_fv_zahlart FOREIGN KEY (zahlungsart_key) REFERENCES dim_zahlungsart (zahlungsart_key)
) ENGINE=InnoDB;

Hinweise: Die Datentypen der Fremdschlüssel müssen zu den Primärschlüsseln der Dimensionen passen. Beträge werden als DECIMAL mit zwei Nachkommastellen gespeichert (nicht FLOAT, nicht DECIMAL(2)). datum_key kann ein sprechender Schlüssel wie 20260820 sein.

Bewertung: 1 Punkt Tabellenname und Grundgerüst, 1 Punkt Primärschlüssel, 2 Punkte passende Datentypen (insbesondere DECIMAL mit Nachkommastellen), 2 Punkte Fremdschlüssel.

f) Bei der Planung stößt Du auf folgenden englischen Text:

In a data warehouse, every dimension table gets its own surrogate key: a simple integer without any business meaning that is generated during the load process. The keys used in the operational systems, such as an article number or a customer number, are called business keys. They are kept as ordinary attributes in the dimension table, so that new facts can be matched to the right dimension row. Fact tables only store the surrogate keys. If a business key changes, for example because a new numbering scheme is introduced after a merger, only one row in the dimension table has to be updated, while the large fact table with years of history remains untouched. Surrogate keys also make it possible to keep several versions of a dimension row, for example when a customer moves.

fa) Erläutere die im Text beschriebenen Vorteile von Surrogatschlüsseln gegenüber den Business-Schlüsseln aus dem Shop. (4 Punkte)

Unabhängigkeit von Änderungen: Business-Schlüssel wie die Artikelnummer haben eine fachliche Bedeutung und können sich ändern (z. B. neues Nummernsystem nach einer Firmenübernahme). Wären sie Fremdschlüssel in der Faktentabelle, müssten alle historischen Faktenzeilen aufwendig angepasst werden. Mit Surrogatschlüsseln wird nur eine Zeile der kleinen Dimensionstabelle geändert; das Data Warehouse ist von den operativen Systemen „abgepuffert“.
Versionen (Historie): Zieht eine Kundin um, kann es zwei Zeilen mit verschiedenen Surrogatschlüsseln, aber demselben Business-Schlüssel geben. Alte Verkäufe bleiben der alten Adresse zugeordnet.

Je Vorteil 2 Punkte (Vorteil nennen und mit Bezug zum Shop erläutern).

fb) Beschreibe, wo im Sternschema der Business-Schlüssel gespeichert wird. (2 Punkte)

Nur in der jeweiligen Dimensionstabelle als normales Attribut (z. B. artikelnr in dim_artikel, kunde_id in dim_kunde), nicht in der Faktentabelle. Beim Laden sucht der ETL-Prozess über ihn den passenden Surrogatschlüssel.

g) Das Data Warehouse ist mit den Shop-Daten befüllt (stornierte Bestellungen wurden nicht übernommen). Formuliere eine SQL-Abfrage, die für das dritte Quartal 2026 den Nettoumsatz je Kategorie und Monat ausgibt, sortiert nach Monat und innerhalb eines Monats nach absteigendem Umsatz. (5 Punkte)

SELECT a.kategorie, d.monat, SUM(f.umsatz_netto) AS umsatz_netto
FROM fakt_verkauf f
  JOIN dim_artikel a ON f.artikel_key = a.artikel_key
  JOIN dim_datum   d ON f.datum_key   = d.datum_key
WHERE d.jahr = 2026 AND d.quartal = 3
GROUP BY a.kategorie, d.monat
ORDER BY d.monat, umsatz_netto DESC;

Ergebnis mit den Daten aus dem Shop:

Nettoumsatz je Kategorie und Monat im dritten Quartal 2026
kategorie	monat	umsatz_netto
Lastenräder	8	3780.67
E-Bikes	8	2436.13
Beleuchtung	8	151.26
Schlösser	8	124.36
Stadträder	9	3424.29
Beleuchtung	9	1285.71
Rahmen	9	756.31
Bremsen	9	120.25

Statt d.quartal = 3 ist auch d.monat BETWEEN 7 AND 9 richtig.

Bewertung: 1 Punkt Spaltenauswahl mit SUM, 1 Punkt JOINs, 1 Punkt WHERE, 1 Punkt GROUP BY, 1 Punkt ORDER BY.

h) Cem Sarıkaya möchte Kategorie und Oberkategorie aus dim_artikel in eigene Tabellen auslagern, „damit die Daten sauber normalisiert sind“. Nimm Stellung zu diesem Vorschlag. (3 Punkte)

Aus dem Sternschema würde ein Schneeflockenschema. Vorteil: Kategoriebezeichnungen stehen nur einmal, eine Umbenennung ist an einer Stelle möglich. Nachteil: Jede Auswertung nach Kategorie braucht zusätzliche JOINs und wird komplexer und langsamer. Da die Dimension klein ist, die Daten nur geladen und gelesen werden und sich die Kategorien selten ändern, ist die Redundanz unproblematisch. Empfehlung: beim Sternschema bleiben.

Bewertung: 1 Punkt Einordnung (Schneeflocke/Normalisierung), 1 Punkt Vor- und Nachteil, 1 Punkt begründete Entscheidung (eine begründete Entscheidung für die Schneeflocke wird ebenfalls anerkannt).

Aufgabe 3.2: Veranstaltungsdaten am Berufskolleg zusammenführen (Profilkompetenz)

(ca. 32 min Bearbeitungszeit)

Das Ratz und Rübe Berufskolleg (RRB) in Bielefeld richtet am 13.03.2027 das Barcamp „Lernen.Digital.Leben 2027“ aus und will künftig jedes Jahr ein Barcamp und eine Ausbildungsbörse mit derselben Software durchführen. Gesamtleiter Dimitrios Papadopoulos möchte die Veranstaltungen anschließend auswerten und vergleichen: Welche Sessions waren voll, welche Räume zu klein, wann kamen die Gäste an? Emre Aksoy, Leiter des Technikteams, und Du sollen die Daten dafür zusammenführen.

Folgende Datenquellen stehen zur Verfügung:

Datenquellen der Veranstaltungsauswertung
Quelle	Inhalt	Format
Anmeldedatenbank auf dem Info-Server	Personen (Name, E-Mail), Anmeldungen mit Ticketart, gebuchte Sessions, Räume und Slots	MariaDB
Check-in-Terminals (zwei Tablets)	Protokoll jedes Check-ins: `lfd_nr;anmeldung_id;terminal;tag;monat;uhrzeit`, z. B. `17;1042;CI-1;13;3;09:41:27`	CSV je Terminal
E-Ink-Türschilder	Messwerte je Raum alle 5 Minuten, z. B. `{"raum": "A.104", "ts": "2027-03-13T11:05:00+01:00", "co2_ppm": 1240, "temp_c": 23.4}`	JSON über die API des Info-Servers
Zähllisten der Helfenden	je Session: Raum („A.104“), Slot („2“), gezählte Personen („31“), Beginn und Ende („11:00“, „11:45“) als Text	Tabellenkalkulation

a) Damit der Check-in auch bei einem Netzausfall funktioniert, speichern die Tablets am Vorabend eine Liste aller gültigen Anmeldungen lokal (dezentral). Svenja Krämer von der Schul-IT OWL würde die Liste lieber nur zentral auf dem Info-Server halten. Beschreibe je zwei Vor- und Nachteile der dezentralen Speicherung auf den Tablets. (8 Punkte)

Vor- und Nachteile der dezentralen Speicherung auf den Tablets
Vorteile der dezentralen Speicherung	Nachteile der dezentralen Speicherung
Der Check-in funktioniert auch, wenn WLAN, Netz oder Info-Server ausfallen; die Schlange am Eingang wächst nicht.	Änderungen nach dem Vorabend (Nachmeldungen, Stornierungen, gesperrte Tickets) fehlen auf den Tablets oder müssen erst verteilt werden.
Die Prüfung erfolgt lokal und damit schneller, ohne Wartezeit auf das Netz; das Netz wird am Morgen weniger belastet.	Die personenbezogenen Daten liegen auf mehreren mobilen Geräten, die verloren gehen oder gestohlen werden können; jedes Tablet muss geschützt (verschlüsselt, gesperrt) werden.
Ein Angriff auf den Server legt den Einlass nicht lahm.	Die Check-ins beider Tablets müssen später zusammengeführt werden; dabei können Daten fehlen oder doppelt sein (Inkonsistenz).

Bewertung: je beschriebenem Vor- oder Nachteil 2 Punkte (zwei Vorteile, zwei Nachteile).

b) Für die Auswertung soll ein kleines Data Warehouse über einen ETL-Prozess befüllt werden. Emre hat dazu folgende Erklärung gefunden:

ETL stands for extract, transform and load. During extraction, data is copied from one or more source systems, for example databases, files or web services, into a staging area. In the transformation step, the data is cleansed, converted into common formats and units, enriched with calculated values and combined. Finally, the load step writes the prepared data into the target system, usually a data warehouse, often in regular batches such as once per night.

ba) Beschreibe mithilfe des Textes die drei Schritte des ETL-Prozesses und beziehe sie auf die Datenquellen des Berufskollegs. (6 Punkte)

Extract (Extraktion): Die relevanten Daten werden aus den verschiedenen Quellen in einen Zwischenbereich (Staging) kopiert: Tabellen aus der Anmeldedatenbank per SQL, die CSV-Dateien beider Check-in-Terminals, die JSON-Messwerte über die API und die Zähllisten aus der Tabellenkalkulation.
Transform (Transformation): Die Daten werden bereinigt (z. B. doppelte Check-ins entfernt), in einheitliche Formate und Einheiten gebracht (Datum, Uhrzeit, Raumbezeichnungen), um berechnete Werte ergänzt (Dauer, Auslastung) und zusammengeführt (Check-ins mit Anmeldungen, Zählungen mit Sessions).
Load (Laden): Die aufbereiteten Daten werden in das Data Warehouse geschrieben, z. B. einmal nach jeder Veranstaltung bzw. regelmäßig nachts.

Je Schritt 2 Punkte.

bb) Nenne drei Attribute aus den Datenquellen, die Du im Rahmen der Transformation anpassen oder neu hinzufügen würdest. Erläutere jeweils den Zweck, und gib den Datentyp an, den das Attribut im Data Warehouse erhält. (9 Punkte)

Drei der folgenden (andere sinnvolle Vorschläge werden anerkannt):

Mögliche Transformationen mit Datentyp und Zweck
Attribut	Anpassung	Datentyp	Zweck
`checkin_zeitpunkt` (neu)	aus `tag`, `monat`, `uhrzeit` und dem Veranstaltungsjahr zusammensetzen	`DATETIME`	Ankunftszeiten über Veranstaltungen und Jahre vergleichen, nach Viertelstunden gruppieren; Datumsfunktionen nutzen
`dauer_min` (neu)	aus Beginn und Ende der Zähllisten berechnen	`SMALLINT`	mit der Dauer rechnen (z. B. Personenminuten je Raum) statt mit Text
`anzahl_personen`	Text „31“ in eine Zahl umwandeln	`SMALLINT`	summieren, Durchschnitt und Auslastung berechnen
`auslastung_prozent` (neu)	gezählte Personen / Plätze des Raums × 100	`DECIMAL(5,1)`	zu kleine oder zu große Räume erkennen
`raum_key` (neu)	Raumbezeichnung „A.104“ aus Zählliste und JSON über die Tabelle `raum` einem Schlüssel zuordnen	`INT`	schnelle, eindeutige Verknüpfung der Quellen, unabhängig von Schreibweisen („A104“, „a.104“)
`messzeitpunkt`	ISO-Zeitstempel mit Zeitzone aus dem JSON umwandeln	`DATETIME`	einheitlich mit den Check-in-Zeiten vergleichen
`slot_nr`	Text „2“ bzw. Uhrzeit dem Slot zuordnen	`TINYINT`	Messwerte und Check-ins den Sessions zuordnen
`lfd_nr`	entfernen	–	Exportnummer ohne Aussagekraft, auf beiden Terminals doppelt vergeben (Hinweis: sinnvolle Transformation, zählt aber nicht als eines der drei Attribute, da ohne Datentyp)
`teilnehmer_pseudonym`	`anmeldung_id` durch ein Pseudonym ersetzen	`CHAR(64)` (Hashwert mit geheimem Schlüssel, z. B. HMAC) bzw. `INT` (Zufallswert aus einer getrennt gespeicherten Zuordnungstabelle)	Auswertung ohne Personenbezug (Datenminimierung); ein einfacher Hash der kleinen `anmeldung_id` ließe sich durch Durchprobieren zurückrechnen

Bewertung: je Attribut 1 Punkt für die Nennung, 1 Punkt für den Zweck, 1 Punkt für einen passenden Datentyp.

c) ca) Gib für jede der vier Datenquellen an, ob sie personenbezogene Daten enthält, und begründe kurz. (4 Punkte)

Personenbezug der Datenquellen
Quelle	personenbezogen?	Begründung
Anmeldedatenbank	ja	Name, E-Mail-Adresse und Buchungen identifizieren Personen direkt.
Check-in-Protokolle	ja	Die `anmeldung_id` lässt sich über die Anmeldedatenbank einer Person zuordnen (pseudonyme Daten sind personenbezogen); zusammen mit der Uhrzeit entsteht ein Ankunftsprotokoll.
Messwerte der Türschilder	nein	CO₂ und Temperatur je Raum enthalten keinen Personenbezug.
Zähllisten	nein	Es werden nur Anzahlen je Session erfasst.

Je Zeile 1 Punkt.

cb) Beschreibe zwei Maßnahmen, die bei der Speicherung der personenbezogenen Daten im Data Warehouse ergriffen werden müssen. (4 Punkte)

Zwei der folgenden, jeweils beschrieben:

Datenminimierung und Pseudonymisierung: Nur Attribute ins Data Warehouse übernehmen, die für die Auswertung nötig sind; Namen und E-Mail-Adressen weglassen, die anmeldung_id durch ein Pseudonym ersetzen oder nur Anzahlen je Viertelstunde und Session speichern (Aggregation).
Löschfristen: Personenbezogene Rohdaten (Check-in-Protokolle, Anmeldungen) nach Abschluss der Auswertung automatisiert löschen; die Datenbank so anlegen, dass Löschen möglich ist (referenzielle Integrität).
Zugriffsschutz: Zugriff nur für berechtigte Rollen (z. B. Orga-Leitung), Schüler*innen im Technikteam arbeiten nur mit anonymisierten Data Marts; Zugriffe protokollieren.
Verschlüsselung: Datenbank und Datenträger (auch die Tablets) verschlüsseln, Übertragung nur über verschlüsselte Verbindungen.
Information und Zweckbindung: Teilnehmende bei der Anmeldung über die Auswertung informieren; Daten nur für die Veranstaltungsplanung verwenden.

Je Maßnahme 2 Punkte.

d) Emre schlägt vor: „Lass uns alle Rohdaten erst einmal unverändert in einen Data Lake kippen. Was wir damit machen, überlegen wir später.“ Erläutere den Unterschied zwischen diesem Vorgehen (ELT) und dem geplanten ETL-Prozess, und beurteile Emres Vorschlag für diesen Fall. (4 Punkte)

Unterschied: Bei ETL werden die Daten vor dem Laden bereinigt und in die feste Struktur des Data Warehouses gebracht. Bei ELT werden die Rohdaten zuerst unverändert gespeichert (Data Lake) und erst bei Bedarf für eine Auswertung umgewandelt. (2 Punkte)
Beurteilung: Für das Berufskolleg spricht wenig für ELT: Die Fragestellungen sind bekannt, die Datenmenge ist klein, und im Data Lake lägen alle personenbezogenen Rohdaten ohne festen Zweck auf Vorrat. Das widerspricht der Zweckbindung und Datenminimierung der DSGVO. Ein ETL-Prozess, der nur benötigte und pseudonymisierte Daten übernimmt, ist hier besser. Allenfalls die Messwerte der Türschilder könnten als Rohdaten aufbewahrt werden. (2 Punkte; eine begründete andere Beurteilung wird anerkannt.)

Links und weitere Informationen

Hinweis zur Nachnutzung als Open Educational Resource (OER)

Dieser Artikel und seine Texte, Bilder, Grafiken, Code und sonstiger Inhalt sind - sofern nicht anders angegeben - lizenziert unter CC BY 4.0. Nennung gemäß TULLU-Regel bitte wie folgt: “Übungsaufgaben zu Data Warehouse, ETL und Sternschema” von oer-informatik.de (H. Stein), Lizenz: CC BY 4.0. Der Artikel wurde unter https://oer-informatik.de/data-warehouse-etl-uebungsaufgaben veröffentlicht, die Quelltexte sind in weiterverarbeitbarer Form verfügbar im Repository unter https://gitlab.com/oer-informatik/daten-ki/datenanalyse-ki. Erstellt mit KI-Assistenz; von mir umfassend redaktionell überarbeitet, geprüft und freigegeben. Stand: 27.10.2026.

[Kommentare zum Artikel lesen, schreiben] / [Artikel teilen] / [gitlab-Issue zum Artikel schreiben]

Übungsaufgaben zu Data Warehouse, ETL und Sternschema