Übungsaufgaben zum Entity-Relationship-Modell

https://bildung.social/@oerinformatik/110195942328913323

https://oer-informatik.de/erm-uebungsaufgaben

ER-Modell, Chen-Notation, Entitätstyp, Beziehungstyp, Kardinalität, Datenbankentwurf, Schwacher Entitätstyp, Übungsaufgaben, Prüfungsvorbereitung

tl/dr; (Bearbeitungszeit insgesamt 121 min, mehrere Aufgaben): Fünf Übungsaufgaben zum konzeptuellen Datenbankentwurf: die Entwurfsphasen ordnen, einen englischen Fachtext auswerten, ER-Diagramme mit Attributen und Schlüsseln aus Anforderungen erstellen, ein ER-Modell aus einem Beleg entwickeln, vorgegebene Modelle erweitern und korrigieren, Zeiträume und Messwerte modellieren und die Überführung ins Relationenmodell beschreiben. Alle Lösungen sind ausgeblendet und mit Punkteverteilung versehen [AI-Assisted]. (Zuletzt geändert am 26.10.2026)

Diese Übungsaufgaben gehören zum Artikel Konzeptueller DB-Entwurf mit dem Entity-Relationship-Modell. Wie es danach weitergeht, zeigen der Artikel Der logische Datenbankentwurf mit dem Relationenmodell und die zugehörigen Übungsaufgaben zum Relationenmodell.

Hinweise zur Bearbeitung: Die Aufgaben sind bewusst umfangreich, damit alle typischen Fragestellungen zum Thema vorkommen; die Angabe hinter dem Aufgabentitel nennt die Kompetenzstufe (Stufe 1 Basiskompetenz bis Stufe 4 Expertise). Zeichne Deine Diagramme auf Papier oder mit einem Werkzeug Deiner Wahl in Chen-Notation (Rechteck = Entitätstyp, Raute = Beziehungstyp, Ellipse = Attribut, Schlüssel unterstrichen) und trage die Kardinalitäten mit 1, n und m ein (c für „höchstens eins“). Fremdschlüssel kennzeichnest Du nur, wenn die Aufgabe es verlangt, mit dem Zusatz „(FK)“. Namen dürfen von der Beispiellösung abweichen, wenn sie selbsterklärend sind; andere fachlich richtige Lösungen sind ebenfalls richtig. In vorgegebenen Diagrammen sind die bereits vorhandenen Elemente grau dargestellt.

Aufgabe 1: Call for Participation für ein Barcamp (Stufe 2 – Kernkompetenz)

(ca. 30 min Bearbeitungszeit)

Du bist Auszubildende*r und arbeitest im Orga-Team des Barcamps „Lernen.Digital.Leben 2027“ am Ratz und Rübe Berufskolleg in Bielefeld mit. Informatiklehrer Dimitrios Papadopoulos möchte, dass die Barcamp-Software auch für künftige Barcamps genutzt werden kann. Für das Modul „Call for Participation“ hat er folgende Anforderungen notiert:

Zu jeder Veranstaltung werden Titel, Datum und Ort gespeichert.
Personen werden mit Vorname, Nachname und E-Mail-Adresse erfasst. Die E-Mail-Adresse ist eindeutig. Auch die Mitglieder des Orga-Teams sind als Personen gespeichert.
Eine Person kann mehrere Sessions einreichen. Jede Session wird von genau einer Person eingereicht und gehört zu genau einer Veranstaltung.
Zu jeder Session werden Titel, Kurzbeschreibung, Format (Vortrag, Workshop oder Diskussion), Status (eingereicht, angenommen, abgelehnt) und der Zeitpunkt der Einreichung gespeichert.
Außer der einreichenden Person können weitere Personen an einer Session mitwirken, eine Person auch an mehreren Sessions. Für jede Mitwirkung wird die Rolle gespeichert (z. B. Ko-Referent*in, Moderation, Schriftdolmetschung).
Jede Session wird von genau zwei Personen des Orga-Teams begutachtet, die dafür Punkte (1 bis 10) und einen Kommentar vergeben. Eine Person des Orga-Teams begutachtet viele Sessions.
Eine Session kann auf einer oder mehreren anderen Sessions aufbauen (z. B. „Mikrocontroller programmieren“ auf „Python für Einsteiger*innen“); eine Session kann Grundlage für mehrere weitere sein. Zu jeder dieser Empfehlungen wird ein kurzer Hinweis für die Teilnehmenden gespeichert.
Für jede Veranstaltung werden Zeitslots festgelegt (Nummer 1 bis 5, Beginn, Ende). Die Slotnummer ist nur innerhalb einer Veranstaltung eindeutig. Räume (Raumnummer, Anzahl der Plätze, barrierefrei ja/nein) werden einmal erfasst und bei jeder Veranstaltung wieder genutzt.
Eine angenommene Session wird genau einem Slot und genau einem Raum zugeordnet; eingereichte und abgelehnte Sessions haben noch keinen Slot und keinen Raum. In einem Slot finden mehrere Sessions statt, in einem Raum über den Tag mehrere.
Von einer Session wird höchstens eine Aufzeichnung veröffentlicht (Dateiname, Dauer, Freigabedatum). Jede Aufzeichnung gehört zu genau einer Session.
In der Übersicht sieht das Orga-Team zu jeder Session die durchschnittliche Punktzahl der Gutachten und die Zahl der Mitwirkenden.

a) Erstelle ein ER-Diagramm in Chen-Notation mit allen genannten Attributen. Kennzeichne die Schlüsselattribute; künstliche Schlüssel sind erlaubt. (25 Punkte)

ER-Diagramm zum Call for Participation mit Veranstaltung, Session, Person, Slot, Raum und Aufzeichnung (Beispiellösung) (mit KI erstellt)

Punkteverteilung (Vorschlag):

Bewertet	Punkte
6 Entitätstypen (Veranstaltung, Session, Person, Slot, Raum, Aufzeichnung) je 1 Punkt	6
9 Beziehungstypen mit beiden Kardinalitäten je 1 Punkt (gehört zu, hat, eingeplant in, findet statt in, baut auf, hat Aufzeichnung, reicht ein, wirkt mit, begutachtet)	9
zusätzlich: Kardinalität `2` bei „begutachtet“ (statt `m`)	1
Attribute der Entitätstypen (je vollständigem Entitätstyp 0,5 Punkte)	3
Attribute an Beziehungen: Rolle; Punkte und Kommentar; Hinweis (je 1 Punkt)	3
Schlüsselattribute gekennzeichnet (alle sechs: 2 Punkte, mindestens vier: 1 Punkt)	2
Durchschnittspunktzahl und Zahl der Mitwirkenden nicht modelliert	1
Summe	25

Erläuterungen und zulässige Varianten:

Drei Beziehungen zwischen Person und Session: Einreichen (1:n), Mitwirken (m:n mit Rolle) und Begutachten sind verschiedene Sachverhalte mit verschiedenen Kardinalitäten. Sie dürfen nicht zu einer Beziehung zusammengefasst werden. Wer die einreichende Person nur als Mitwirkung mit der Rolle „Einreichung“ modelliert, verliert die Information, dass es genau eine einreichende Person gibt (Abzug 1 Punkt).
„genau zwei“: Die feste Zahl steht an der Seite der Person, weil zu einer Session genau zwei Personen gehören. Auch n statt 2 mit einem Hinweis „genau 2“ ist richtig. Ein separater Entitätstyp Orga-Mitglied ist vertretbar, wenn er mit Person verbunden ist; ohne diese Verbindung entstehen doppelte Personendaten.
Rekursive Beziehung „baut auf“: zwei Linien von derselben Raute zu Session; die Rollen („baut auf“ / „ist Grundlage für“) können an die Linien geschrieben werden. Der Hinweis gehört an die Beziehung, weil er von beiden Sessions abhängt.
Slot ist hier als schwacher Entitätstyp mit identifizierender Beziehung zur Veranstaltung gezeichnet, weil die Nummer nur innerhalb einer Veranstaltung eindeutig ist. Ein normaler Entitätstyp mit künstlichem Schlüssel SlotID ist ebenfalls richtig.
Slot und Raum: Statt zweier Beziehungen ist auch eine Beziehung mit drei Beteiligten eingeplant (Session, Slot, Raum) richtig. Wer Optionalitäten notiert, schreibt bei Slot und Raum c (eine Session hat höchstens einen Slot) und bei Session nc.
Aufzeichnung: 1:c (höchstens eine). 1:1 wird mit 0,5 Punkten bewertet. Ein künstlicher Schlüssel AufzeichnungID ist ebenfalls richtig; die Aufzeichnung kann auch als schwacher Entitätstyp gezeichnet werden.
Abgeleitete Werte: Durchschnittspunktzahl und Zahl der Mitwirkenden lassen sich jederzeit aus den Gutachten bzw. Mitwirkungen berechnen. Werden sie als gestrichelte Ellipse (abgeleitetes Attribut) eingezeichnet, ist das ebenfalls richtig.
Format und Status sind hier Attribute. Eigene Entitätstypen sind ebenfalls richtig (siehe b).

b) Mia Schröder schlägt vor, das Format der Sessions nicht als Attribut, sondern als eigenen Entitätstyp Format zu modellieren. Beschreibe je einen Vorteil und einen Nachteil dieses Vorschlags. (4 Punkte)

Je 2 Punkte, z. B.:

Vorteil: Die Formate werden nur einmal gespeichert und können als Auswahlliste gepflegt werden. Es gibt keine unterschiedlichen Schreibweisen („Workshop“, „workshop“, „WS“), und eine Umbenennung muss nur an einer Stelle erfolgen (keine Änderungsanomalie). Neue Formate (z. B. „Lightning Talk“) lassen sich ohne Strukturänderung ergänzen, und zum Format können weitere Angaben gespeichert werden (z. B. Standarddauer, benötigte Technik).
Nachteil: Das Modell wird größer: ein zusätzlicher Entitätstyp und eine zusätzliche Beziehung, später eine weitere Tabelle mit Fremdschlüssel. Abfragen brauchen einen zusätzlichen Verbund (Join). Bei drei feststehenden Werten ist der Nutzen gering; eine Werteliste (z. B. ENUM oder CHECK) beim Attribut reicht dann aus.

c) Mia soll das ER-Modell später in ein Relationenmodell überführen. Erläutere, wie sie dabei die Beziehungen „begutachtet“ und „baut auf“ umsetzen muss. Nenne außerdem eine Anforderung aus a), die sich dabei nicht allein über Primär- und Fremdschlüssel absichern lässt. (4 Punkte)

begutachtet (1,5 Punkte): Die Beziehung ist eine n:m-Beziehung (2:n). Sie wird zu einer eigenen Zwischentabelle, z. B. gutachten (session_id (PK, FK), person_id (PK, FK), punkte, kommentar). Die Attribute der Beziehung kommen in diese Tabelle; der Primärschlüssel setzt sich aus beiden Fremdschlüsseln zusammen.
baut auf (1,5 Punkte): Auch die rekursive m:n-Beziehung wird eine Zwischentabelle, deren beide Fremdschlüssel auf session verweisen. Sie brauchen unterschiedliche, sprechende Namen, z. B. aufbau (session_id (PK, FK), grundlage_session_id (PK, FK), hinweis).
Nicht über Schlüssel absicherbar (1 Punkt): „genau zwei Gutachten je Session“ – Schlüssel verhindern nur, dass dieselbe Person eine Session zweimal begutachtet, nicht aber, dass es nur eines oder drei Gutachten gibt. Das muss die Anwendung (oder ein Trigger) prüfen. Ebenfalls richtig: „nur angenommene Sessions haben Slot und Raum“, „Punkte von 1 bis 10“ (hier hilft ein CHECK-Constraint), „eine Session baut nicht auf sich selbst auf“.

Aufgabe 2: Fertigung und Reklamationen im Fahrrad-Onlineshop (Stufe 2 – Kernkompetenz)

(ca. 34 min Bearbeitungszeit)

Du bist Auszubildende*r im Entwicklungsteam der CSB-Rad GmbH in Bielefeld. Die Kundschaft soll im Kundenkonto künftig sehen, wie weit die Fertigung ihres Individualrahmens ist. Ole Petersen, Projektleiter Digitalisierung bei der Rahmenwerk OWL GmbH in Gütersloh, hat Cem Sarıkaya dazu ein Fertigungsblatt aus dem MES geschickt, dessen Inhalte künftig an den Shop übertragen werden sollen:

Rahmenwerk OWL GmbH · Gütersloh                               FERTIGUNGSBLATT
MES-Auftrag 1041        Kundenauftrag CSB-Rad: Bestellung 1, Position 1
Eingang: 12.08.2026     Liefertermin: 30.10.2026

Rahmen     Form: Lastenrad-Long-John (LJ)   Rahmenhöhe: 52 cm
           Farbe: RAL 6018 Gelbgrün         Oberfläche: matt
           Gravur: „Okafor-Schmidt“         RFID-Tag: E200 3412 0126 0041

Rohrsatz
Pos  Mat.-Nr.  Bezeichnung          Werkstoff     Ø/Profil   Länge   Lieferant
1    AL-35-61  Oberrohr             Alu 6061-T6   35 mm      560 mm  Alu-Profil Bielefeld GmbH
2    AL-44-61  Unterrohr            Alu 6061-T6   44 mm      690 mm  Alu-Profil Bielefeld GmbH
3    AL-35-61  Sitzrohr             Alu 6061-T6   35 mm      480 mm  Alu-Profil Bielefeld GmbH
4    AL-56-70  Steuerrohr           Alu 7020      56 mm      125 mm  Senne-Metall KG
5    AL-4020   Ladeflächenrahmen    Alu 6061-T6   40×20 mm  2.480 mm  Alu-Profil Bielefeld GmbH
                                                Summe Rohrlänge: 4.335 mm

Arbeitsschritte
Nr  Schritt            Anlage(n)                        durchgeführt von   Start             Ende              Dauer
10  Rohre biegen       Biegezelle BZ-2                  Arda Şahin         12.10. 07:10      12.10. 08:05      0:55
20  Schweißen          Roboterschweißzelle RZ-1         Arda Şahin         13.10. 09:30      13.10. 11:15      1:45
30  Pulverbeschichten  Pulverkabine PK-1, Ofen EO-1     Kerstin Brockmann  16.10. 06:40      –                 –
40  Endkontrolle       Messplatz MP-1                   –                  –                 –                 –

Ole Petersen ergänzt im Gespräch:

Rahmenformen und Farben stammen aus festen Katalogen; zu jeder Farbe werden RAL-Code und Name gespeichert.
Ein Rohr (Materialnummer) wird immer von genau einem Lieferanten bezogen; ein Lieferant liefert viele Rohre. Dasselbe Rohr kann in einem Auftrag mehrfach vorkommen (Positionen 1 und 3).
Die Arbeitsschritte (Biegen, Schweißen …) sind als Schrittarten hinterlegt. Ein Arbeitsschritt eines Auftrags kann mehrere Anlagen nutzen; jede Anlage wird für viele Arbeitsschritte genutzt. Jeder Arbeitsschritt wird von genau einer Mitarbeiterin oder einem Mitarbeiter durchgeführt.
Die Daten der Bestellung selbst (Kundin, Preis …) liegen nur im Shop; das MES speichert lediglich die Bestell- und Positionsnummer.

a) Entwickle aus dem Fertigungsblatt und den Ergänzungen ein ER-Modell. Das Modell soll die Entitätstypen und ihre Beziehungen mit Kardinalitäten enthalten, jedoch keine Attribute. (17 Punkte)

ER-Modell zum Fertigungsblatt mit Fertigungsauftrag, Rahmenform, Farbe, Rohr, Lieferant, Arbeitsschritt, Schrittart, Anlage und Mitarbeiter*in (Beispiellösung) (mit KI erstellt)

Punkteverteilung (Vorschlag): 9 Entitätstypen je 1 Punkt (9 Punkte), 8 Beziehungen mit beiden Kardinalitäten je 1 Punkt (8 Punkte).

Erläuterungen und zulässige Varianten:

Analyse des Belegs: Die Kopfangaben (Form, Farbe) verweisen auf Kataloge und werden eigene Entitätstypen; die beiden Tabellen auf dem Beleg (Rohrsatz, Arbeitsschritte) sind Wiederholgruppen und führen zu einer m:n-Beziehung (benötigt) bzw. zu einem eigenen Entitätstyp (Arbeitsschritt).
Nicht modelliert werden die Summe der Rohrlängen und die Dauer – beide lassen sich berechnen. Rahmenhöhe, Oberfläche, Gravur, RFID-Tag, Eingang, Liefertermin sowie Bestell- und Positionsnummer sind Attribute des Fertigungsauftrags (hier nicht verlangt). Die Länge und die Positionsnummer gehören an die Beziehung benötigt.
Oberfläche als eigener Entitätstyp ist ebenfalls richtig. Ein Entitätstyp Bestellung oder Kunde ist hier nicht sinnvoll, weil das MES diese Daten nicht speichert (kein Abzug, wenn er mit einer Beziehung sauber angebunden ist).
Rohrsatz: Da dasselbe Rohr mehrfach im Auftrag vorkommt, ist auch ein eigener (schwacher) Entitätstyp Rohrposition richtig, der mit Fertigungsauftrag (1:n) und Rohr (n:1) verbunden ist. Wer nur einen Entitätstyp Rohr ohne Lieferant zeichnet, verliert 2 Punkte.
Arbeitsschritt hängt vom Fertigungsauftrag ab (die Schrittnummer 10, 20 … ist nur innerhalb eines Auftrags eindeutig) und ist deshalb als schwacher Entitätstyp gezeichnet. Ein normaler Entitätstyp ist ebenfalls richtig. Falsch ist eine direkte m:n-Beziehung zwischen Fertigungsauftrag und Schrittart ohne eigenen Arbeitsschritt, weil dann die Anlagen und die durchführende Person keinem Schritt zugeordnet werden können (Abzug 2 Punkte).
Mitarbeiter*in: Ein noch nicht begonnener Schritt hat (noch) niemanden. Wer das als Optionalität notiert (c an Mitarbeiter*in), erhält ebenfalls die volle Punktzahl.

b) Für den Onlineshop gibt es bereits das folgende ER-Modell (Ausschnitt):

Vorhandenes ER-Modell des Onlineshops mit Kunde, Bestellung, Artikel, Mitarbeiter*in und Dokument (mit KI erstellt)

Natalia Wróbel aus der Buchhaltung und Sophie Bertram haben neue Anforderungen für die Bearbeitung von Reklamationen gesammelt:

Kund*innen können zu einer Bestellung eine oder mehrere Reklamationen melden. Zu jeder Reklamation wird eine Beschreibung gespeichert.
Reklamationen werden streng in der Reihenfolge bearbeitet, in der sie eingehen.
Eine Reklamation betrifft einen oder mehrere Artikel; je Artikel wird die beanstandete Menge erfasst.
Jede Reklamation wird von genau einer Mitarbeiterin oder einem Mitarbeiter bearbeitet. Beim Abschluss werden das Ergebnis (Ersatz, Reparatur, Gutschrift, abgelehnt) und der Zeitpunkt des Abschlusses gespeichert.
Kund*innen können eine Reklamation zurücknehmen. Sie muss trotzdem gespeichert bleiben, weil sie als Nachweis für die Gewährleistung dient.
Zu einer Reklamation können mehrere Fotos hochgeladen werden (Dateiname, Zeitpunkt des Hochladens).
Zu jedem Artikel gibt es Montage- und Garantiedokumente, die bereits zentral gespeichert sind. Ein Dokument kann für mehrere Artikel gelten.

Erweitere das ER-Modell, sodass die Anforderungen abgedeckt sind. Ergänze dabei die notwendigen Attribute. (12 Punkte)

Erweitertes ER-Modell mit Reklamation, Foto und den neuen Beziehungen (Beispiellösung; vorhandene Elemente grau) (mit KI erstellt)

Punkteverteilung (Vorschlag):

Bewertet	Punkte
Entitätstypen Reklamation und Foto je 1 Punkt	2
Beziehungen betrifft, bearbeitet, beanstandet, hat (Foto), gilt für – je 1 Punkt mit beiden Kardinalitäten	5
Attribute Beschreibung, Eingangszeitpunkt, Ergebnis, Abschlusszeitpunkt, Rücknahme, Menge an „beanstandet“, Dateiname, Hochladezeitpunkt – je 0,5 Punkte	4
vorhandene Entitätstypen genutzt, keine zusätzliche Beziehung Kunde–Reklamation	1
Summe	12

Erläuterungen und zulässige Varianten:

Reihenfolge: Der Eingangszeitpunkt legt die Bearbeitungsreihenfolge fest. Eine fortlaufende Nummer ist ebenfalls richtig.
Zurücknehmen ohne Löschen: Ein Zeitpunkt zurückgenommen am (leer, solange die Reklamation aktiv ist) dokumentiert zugleich, wann zurückgenommen wurde. Ein Attribut zurückgenommen (ja/nein) oder ein Status (offen, in Bearbeitung, abgeschlossen, zurückgenommen) ist ebenfalls richtig.
Ergebnis kann auch als eigener Entitätstyp Ergebnisart modelliert werden. Ergebnis und Abschlusszeitpunkt können alternativ an der Beziehung „bearbeitet“ stehen.
Kunde: Die Kundin oder der Kunde ist über die Bestellung schon mit der Reklamation verbunden. Eine zusätzliche Beziehung wäre doppelt und könnte widersprüchlich werden (Reklamation einer anderen Person als der Besteller*in).
Strengere Variante: Genau genommen darf eine Reklamation nur Artikel betreffen, die in dieser Bestellung enthalten sind. Das lässt sich ausdrücken, indem die Beziehung enthält zu einem Entitätstyp Bestellposition gemacht wird und beanstandet die Reklamation mit der Bestellposition verbindet. Diese Lösung ist ebenfalls richtig.
Foto ist als schwacher Entitätstyp gezeichnet (ein Foto gibt es nur zu einer Reklamation). Ein normaler Entitätstyp mit FotoID ist ebenfalls richtig, ein mehrwertiges Attribut Fotos an Reklamation nicht, weil zu jedem Foto zwei Angaben gespeichert werden.
Dokument: Der vorhandene Entitätstyp wird über eine m:n-Beziehung angebunden – ein Artikel hat mehrere Dokumente, ein Dokument gilt für mehrere Artikel.

c) Für die gleichschließenden Schlösser hat Dein Mit-Azubi Jonas einen ersten Entwurf gezeichnet. Cem Sarıkaya hatte ihm diese Anforderungen gegeben:

Kund*innen bestellen Schließanlagen. Jede Schließanlage gehört zu genau einer Kundin oder einem Kunden; eine Person kann mehrere Schließanlagen haben.
Eine Schließanlage (eindeutiger Schließungscode) umfasst ein oder mehrere Schlösser. Ein Schloss gehört zu höchstens einer Schließanlage, denn Einzelschlösser ohne Schließanlage sind möglich.
Jedes Schloss hat eine Seriennummer und ist von genau einem Schlosstyp (z. B. Bügelschloss, Rahmenschloss). Bezeichnung und Preis hängen nur vom Schlosstyp ab.
Im Shop wird zu jeder Schließanlage angezeigt, wie viele Schlösser zu ihr gehören.

Entwurf von Jonas für Kunde, Schließanlage, Schloss und Schlosstyp mit fehlenden Kardinalitäten (mit KI erstellt)

Vervollständige die mit ? markierten Kardinalitäten und korrigiere drei fachliche Fehler im Entwurf. Begründe jede Korrektur in einem Satz. (8 Punkte)

Korrigierter Entwurf mit vollständigen Kardinalitäten (Beispiellösung) (mit KI erstellt)

Kardinalitäten (je 1 Punkt, 2 Punkte):

bestellt: 1 bei Kunde, n bei Schließanlage – eine Schließanlage gehört genau einer Person, eine Person kann mehrere haben.
ist vom Typ: 1 bei Schlosstyp, n bei Schloss.

Fehler (je 2 Punkte: 1 Punkt Korrektur, 1 Punkt Begründung, 6 Punkte):

Kardinalität bei umfasst: m muss durch 1 (genauer c) ersetzt werden, weil ein Schloss zu höchstens einer Schließanlage gehört. Mit m:n könnte ein Schloss in mehreren Schließanlagen stecken, was technisch unmöglich ist.
Attribut Kundenname an Schließanlage: entfernen, weil der Name schon beim Kunden gespeichert ist und über die Beziehung bestellt erreichbar ist. Doppelte Speicherung führt bei einer Namensänderung zu widersprüchlichen Daten (Änderungsanomalie).
Attribut Anzahl Schlösser: entfernen, weil sich die Anzahl aus der Beziehung umfasst berechnen lässt (abgeleiteter Wert). Gespeichert müsste sie bei jedem neuen oder entfernten Schloss nachgeführt werden. (Alternativ als abgeleitetes Attribut mit gestrichelter Ellipse kennzeichnen.)

Weitere fachlich richtige Hinweise werden anerkannt, z. B. dass die Beziehung ist vom Typ korrekt ist, weil Bezeichnung und Preis nur vom Schlosstyp abhängen und deshalb nicht beim Schloss stehen.

Aufgabe 3: Treffpunkte für eine Freizeit-App modellieren (Stufe 1 – Basiskompetenz)

(ca. 14 min Bearbeitungszeit)

Du unterstützt bei der Let’s Meet GmbH in Bielefeld das Entwicklungsteam von Yusuf Demir. Nutzer*innen wie Lea Schmitt, die einen Rollstuhl nutzt, wünschen sich einen verlässlichen Filter für die Ausstattung der Treffpunkte. Dafür soll die Datenbank der App erweitert werden.

a) Yusuf Demir hat die Arbeitsschritte für die Erweiterung der Datenbank auf Karteikarten notiert, sie sind aber durcheinandergeraten. Die Anforderungsanalyse ist bereits als erster Schritt eingetragen. Bringe die übrigen Schritte A bis F in die richtige Reihenfolge. (3 Punkte)

Arbeitsschritte des Datenbankentwurfs (ungeordnet)
Karte	Arbeitsschritt
A	Die Tabellen werden mit SQL-Befehlen im Datenbankmanagementsystem angelegt, Datentypen und Indizes werden festgelegt.
B	Ein ER-Diagramm beschreibt die benötigten Entitätstypen, Attribute und Beziehungen unabhängig von der späteren Speicherung.
C	Mit Testdaten wird geprüft, ob alle Anforderungen erfüllt sind und die Abfragen die erwarteten Ergebnisse liefern.
D	Das ER-Modell wird in Relationen mit Primär- und Fremdschlüsseln überführt.
E	Die Datenbank wird genutzt, gesichert und bei neuen Anforderungen angepasst.
F	Es wird festgelegt, welche Daten auf welchem Server bzw. an welchem Standort gespeichert werden.

Reihenfolge der Arbeitsschritte
1	2	3	4	5	6	7
Anforderungsanalyse

Reihenfolge der Arbeitsschritte (Beispiellösung)
1	2	3	4	5	6	7
Anforderungsanalyse	B	D	F	A	C	E

Die Schritte entsprechen den Phasen konzeptueller Entwurf (B), logischer Entwurf (D), Verteilungsentwurf (F), physischer Entwurf bzw. Implementierung (A), Test und Validierung (C) sowie Anwendung und Wartung (E).

Bewertung: je richtig eingetragenem Feld 0,5 Punkte.

b) Yusuf Demir schickt Dir einen Auszug aus einem englischen Fachartikel:

An entity-relationship model describes the data of an application on a conceptual level. Entity types represent things the business cares about, such as meeting points or activities, and each of them is described by attributes. Relationships connect entity types. Their cardinality tells how many entities on one side can be related to a single entity on the other side. If a piece of information depends on both participants of a relationship – for example the date on which a feature of a meeting point was last checked – it is attached to the relationship itself and not to one of the entity types.

Beantworte die folgenden Fragen auf Deutsch und mit Bezug zum Text.

ba) Beschreibe, was die Kardinalität eines Beziehungstyps angibt. (2 Punkte)

Die Kardinalität gibt an, mit wie vielen Entitäten auf der einen Seite einer Beziehung eine einzelne Entität auf der anderen Seite verbunden sein kann (z. B. eine Aktivität findet an einem Treffpunkt statt, an einem Treffpunkt finden viele Aktivitäten statt).

Bewertung: 2 Punkte für eine sinngemäß richtige Beschreibung; andere Formulierungen sind möglich.

bb) Beschreibe, wann ein Attribut an einen Beziehungstyp statt an einen Entitätstyp gehört, und nenne das Beispiel aus dem Text. (2 Punkte)

Ein Attribut gehört an den Beziehungstyp, wenn es von beiden beteiligten Entitäten gemeinsam abhängt (1 Punkt). Beispiel im Text: das Datum, an dem ein Merkmal eines Treffpunkts zuletzt geprüft wurde (1 Punkt).

c) Modelliere den folgenden Ausschnitt als ER-Diagramm in Chen-Notation. Der Entitätstyp Aktivität ist bereits vorgegeben. Gib die Kardinalitäten an und ordne die Attribute aus der Tabelle richtig zu. (8 Punkte)

Jede Aktivität findet an genau einem Treffpunkt statt. An einem Treffpunkt finden viele Aktivitäten statt.
Für Treffpunkte werden Merkmale gespeichert, z. B. „rollstuhlgerecht“, „WC vorhanden“ oder „überdacht“. Ein Treffpunkt kann mehrere Merkmale haben, und ein Merkmal kann für viele Treffpunkte gelten.
Für jedes Merkmal eines Treffpunkts wird gespeichert, wann es zuletzt geprüft wurde, und ein kurzer Hinweis (z. B. „Rampe am Seiteneingang“).

Mindestens zu speichernde Attribute
Attribut	Bedeutung
AID	eindeutige Nummer der Aktivität
Titel	Titel der Aktivität
Beginn	Datum und Uhrzeit des Beginns
TID	eindeutige Nummer des Treffpunkts
NameT	Name des Treffpunkts
PLZ	Postleitzahl des Treffpunkts
MID	eindeutige Nummer des Merkmals
Bezeichnung	Bezeichnung des Merkmals
GeprueftAm	Datum der letzten Prüfung eines Merkmals an einem Treffpunkt
Hinweis	Hinweis zu einem Merkmal an einem Treffpunkt

Hinweis: Kennzeichne alle Primärschlüssel durch Unterstreichen. Fremdschlüssel musst Du nicht angeben.

ER-Diagramm mit Aktivität, Treffpunkt und Merkmal; die Beziehung „hat“ trägt die Attribute GeprueftAm und Hinweis (Beispiellösung) (mit KI erstellt)

Bewertung:

Entitätstypen Treffpunkt und Merkmal: je 1 Punkt (2 Punkte)
Beziehung findet statt an mit n:1 und Beziehung hat mit m:n: je 1 Punkt (2 Punkte)
Primärschlüssel in allen drei Entitätstypen unterstrichen: 1 Punkt
übrige Attribute sinnvoll zugeordnet: 2 Punkte
GeprueftAm und Hinweis am Beziehungstyp hat: 1 Punkt

Andere Lösungen sind möglich: Statt der m:n-Beziehung mit Attributen kann ein eigener Entitätstyp (z. B. Ausstattung mit GeprueftAm und Hinweis) mit zwei 1:n-Beziehungen zu Treffpunkt und Merkmal modelliert werden. Stehen GeprueftAm und Hinweis bei Treffpunkt oder Merkmal, gibt es dafür keinen Punkt: Ein Treffpunkt mit mehreren Merkmalen hätte dann nur ein Prüfdatum.

Aufgabe 4: Störungen an den Flurmonitoren einer Mitfahr-App (Stufe 1 – Basiskompetenz)

(ca. 14 min Bearbeitungszeit)

Am Ratz und Rübe Berufskolleg zeigen vier Flurmonitore die offenen Angebote und Gesuche der Mitfahr-App „RatzFahrt“. Jeder Monitor wird von einem Mini-Player angesteuert. Weil der Monitor am Parkplatzausgang immer wieder ausfällt, möchte Svenja Krämer von der Schul-IT OWL Störungen und ihre Bearbeitung in der Datenbank dokumentieren. Sie hat Dir den folgenden Ausschnitt des ER-Modells gegeben.

Vorgegebenes ER-Modell mit Mini-Player, Monitor und Mitarbeiter*in; die Kardinalitäten der Beziehung „steuert“ fehlen (mit KI erstellt)

a) Jeder Monitor wird von genau einem Mini-Player angesteuert, und ein Mini-Player steuert genau einen Monitor. Ergänze die Kardinalitäten der Beziehung steuert und erläutere an diesem Beispiel, was die Kardinalität bedeutet. (3 Punkte)

Kardinalität 1:1 (an beiden Linienenden 1), siehe Diagramm in der Beispiellösung zu b) (1 Punkt).

Erläuterung (2 Punkte): Zu einem bestimmten Monitor gehört genau ein Mini-Player, und ein bestimmter Mini-Player ist genau einem Monitor zugeordnet. Ein Player kann also nicht mehrere Monitore ansteuern, und ein Monitor wird nicht von mehreren Playern angesteuert.

b) Erweitere das Modell redundanzfrei um die Störungen. Jeder Entitätstyp soll einen Primärschlüssel haben. (7 Punkte)

Zu jeder Störung werden eine Beschreibung und der Zeitpunkt der Meldung gespeichert.
Ein Monitor kann im Lauf der Zeit viele Störungen haben, eine Störung betrifft genau einen Monitor.
Jede Störung wird von genau einer Mitarbeiterin bzw. einem Mitarbeiter der Schul-IT bearbeitet. Beginn und Ende der Bearbeitung werden festgehalten.
Von den Mitarbeitenden soll zusätzlich der Vorname gespeichert werden.

ER-Modell mit Störung und Tätigkeit, Beziehungen „betrifft“, „bearbeitet“, „umfasst“ und „führt aus“ sowie dem neuen Attribut Vorname (Beispiellösung; vorgegebene Elemente grau) (mit KI erstellt)

Die Beispiellösung enthält auch die Ergänzungen aus a) und c).

Bewertung:

Entitätstyp Störung: 1 Punkt
Attribute Störungsnummer (unterstrichen), Beschreibung, gemeldet am, Beginn, Ende: 2 Punkte
Beziehungen betrifft und bearbeitet: je 1 Punkt (2 Punkte)
Kardinalitäten 1:n an beiden Beziehungen: 1 Punkt
Vorname beim vorhandenen Entitätstyp Mitarbeiter*in: 1 Punkt

Redundanzfrei heißt hier: Der Vorname gehört zum vorhandenen Entitätstyp Mitarbeiter*in und nicht noch einmal zur Störung; der Monitor wird nicht doppelt angelegt. Beginn und Ende dürfen auch an der Beziehung bearbeitet stehen, weil jede Störung nur einmal bearbeitet wird.

c) Die Bearbeitung einer Störung besteht aus einer oder mehreren Tätigkeiten, z. B. „Player neu gestartet“ oder „Netzwerkdose durchgemessen“. Zu jeder Tätigkeit werden eine Beschreibung, das Ergebnis sowie Start und Ende gespeichert. Jede Tätigkeit wird von genau einer Person der Schul-IT ausgeführt – das muss nicht die Person sein, die die Störung bearbeitet. Ergänze das ER-Modell um die fehlenden Elemente. (5 Punkte)

Siehe Diagramm in der Beispiellösung zu b): Entitätstyp Tätigkeit mit Tätigkeitsnummer (unterstrichen), Beschreibung, Ergebnis, Start, Ende; Beziehung umfasst (Störung 1 : n Tätigkeit) und Beziehung führt aus (Mitarbeiter*in 1 : n Tätigkeit).

Bewertung: Entitätstyp mit Primärschlüssel 1 Punkt, übrige Attribute 2 Punkte, zwei Beziehungen mit Kardinalitäten je 1 Punkt.

Die zweite Beziehung zu Mitarbeiter*in ist nötig, weil die ausführende Person von der bearbeitenden abweichen kann. Eine Dauer der Tätigkeit wird nicht gespeichert, sie lässt sich aus Start und Ende berechnen.

Aufgabe 5: Ein Buchungsportal für Dienst-Lastenräder (Stufe 2 – Kernkompetenz)

(ca. 29 min Bearbeitungszeit)

Die CSB-Rad GmbH entwickelt für den Zweckverband Radwege OWL ein Portal, über das die Beschäftigten der Außenstellen zwölf Dienst-Lastenräder buchen können. Jedes Rad ist mit einem Smartlock ausgestattet, das sich per App öffnen lässt. Du arbeitest im Team von Cem Sarıkaya am Datenmodell mit. Michael Hartmann, der beim Zweckverband den Fuhrpark verantwortet, begleitet das Projekt.

a) Michael Hartmann wundert sich, dass im ER-Modell weder Tabellen noch Datentypen vorkommen. Cem Sarıkaya erklärt, das ER-Modell gehöre zur konzeptionellen Ebene des Datenbankentwurfs. Beschreibe diese Aussage anhand von zwei Aspekten. (4 Punkte)

Je Aspekt 2 Punkte, z. B.:

Implementierungsunabhängig: Das ER-Modell legt noch nicht fest, ob die Daten später relational (in Tabellen), in Dokumenten oder in einem Graphen gespeichert werden, und welches DBMS genutzt wird. Datentypen, Tabellen und Constraints hängen davon ab und werden erst im logischen bzw. physischen Entwurf festgelegt.
Fachliche Sicht und gemeinsame Sprache: Es beschreibt den Ausschnitt der realen Welt (Räder, Buchungen, Außenstellen) mit Entitätstypen, Attributen und Beziehungen so, dass Auftraggeber und Entwicklung es gemeinsam besprechen und prüfen können, ob alle Anforderungen erfasst sind.
Grundlage der folgenden Phasen: Es ist das Ergebnis der ersten Entwurfsphase nach der Anforderungsanalyse und wird anschließend in ein logisches Modell (z. B. Relationenmodell) überführt.

b) Das Team hat den folgenden Entwurf begonnen. Ein Entitätstyp ist noch nicht benannt.

Begonnener Entwurf mit einem unbenannten Entitätstyp, Außenstelle, Buchung, Lastenrad und Smartlock (mit KI erstellt)

Vervollständige das ER-Modell mit allen fehlenden Entitätstypen, Attributen, Beziehungen und Kardinalitäten. Kennzeichne in allen Entitätstypen die Primärschlüssel durch Unterstreichen und die Fremdschlüssel mit dem Zusatz „(FK)“. (12 Punkte)

Beschäftigte nehmen Buchungen vor. Eine Buchung gilt immer für genau ein Lastenrad; ein Lastenrad kann oft gebucht werden.
Jedes Lastenrad ist mit genau einem Smartlock ausgestattet. Ein Smartlock gehört zu höchstens einem Lastenrad; einige Smartlocks liegen als Ersatz im Lager.
Die Lastenräder werden je nach Bedarf an wechselnden Außenstellen stationiert. Es muss nachvollziehbar sein, an welcher Außenstelle ein Rad von wann bis wann stationiert war. Bei der aktuellen Stationierung ist das Ende noch nicht bekannt.

Vervollständigtes ER-Modell mit Beschäftigte*r, Buchung, Lastenrad, Smartlock, Außenstelle und Stationierung samt Primär- und Fremdschlüsseln (Beispiellösung; vorgegebene Elemente grau) (mit KI erstellt)

Bewertung:

Entitätstyp Beschäftigte*r benannt: 1 Punkt
Entitätstyp Stationierung mit Stationierungs-ID (unterstrichen), von und bis: 3 Punkte
bis bleibt bei der aktuellen Stationierung leer (NULL); erkennbar z. B. an einer Anmerkung oder im Text: 1 Punkt
Beziehung gilt für (Buchung n : 1 Lastenrad): 1 Punkt
Beziehung ist ausgestattet mit mit Kardinalität 1 beim Smartlock und c (höchstens eins) beim Lastenrad: 2 Punkte
Beziehungen erfolgt an und betrifft mit 1:n: je 1 Punkt (2 Punkte)
Fremdschlüssel Stellen-ID bei Beschäftigte*r, Personalnummer und Rad-ID bei Buchung, Schloss-ID bei Lastenrad, Rad-ID und Stellen-ID bei Stationierung: 2 Punkte

Andere Lösungen sind möglich:

Die Stationierung kann als m:n-Beziehung ist stationiert an zwischen Lastenrad und Außenstelle mit den Attributen von und bis modelliert werden. Weil dasselbe Rad mehrmals an derselben Außenstelle stehen kann, muss von dann später Teil des Schlüssels werden.
Statt der künstlichen Stationierungs-ID ist ein zusammengesetzter Primärschlüssel aus Rad-ID und von möglich (ein Rad steht zu einem Zeitpunkt nur an einer Außenstelle).
Der Fremdschlüssel der 1:c-Beziehung darf auch beim Smartlock stehen (Rad-ID (FK), bei Ersatzschlössern leer).

Eine zusätzliche direkte Beziehung zwischen Lastenrad und Außenstelle („steht aktuell an“) wäre redundant, weil die aktuelle Stationierung schon an dem leeren bis zu erkennen ist.

c) Die Smartlocks senden alle fünf Minuten eine Statusmeldung mit folgenden Werten:

Schloss-ID
Zeitstempel der Meldung
Akkustand in Prozent
GPS-Position
Status (offen/geschlossen)
Restreichweite in km (vom Smartlock aus dem Akkustand berechnet)
Akkustand vor 24 Stunden

Die Fuhrparkverwaltung möchte auswerten, wie schnell die Akkus der Räder im Alltag leer werden und wann sie geladen werden müssen.

ca) Nenne die drei Werte, die für diese Auswertung in der Datenbank gespeichert werden müssen, und begründe Deine Auswahl. (6 Punkte)

Je Wert 1 Punkt, je Begründung 1 Punkt:

Schloss-ID: ordnet die Meldung über die Beziehung ist ausgestattet mit dem Lastenrad zu.
Zeitstempel: Nur mit dem Zeitpunkt lässt sich der Verlauf des Akkustands über die Zeit darstellen.
Akkustand: ist der eigentliche Messwert, aus dem Entladegeschwindigkeit und Ladezeitpunkte folgen.

Nicht gespeichert werden müssen: die Restreichweite und der Akkustand vor 24 Stunden, weil sie sich aus den gespeicherten Werten berechnen lassen (abgeleitete bzw. doppelte Werte), sowie GPS-Position und Status, weil sie für diesen Zweck nicht nötig sind. Die GPS-Position würde zudem ein Bewegungsprofil der Beschäftigten ermöglichen (Grundsatz der Datenminimierung, Art. 5 Abs. 1 lit. c DSGVO).

cb) Entscheide begründet, ob es sich bei den gespeicherten Statusmeldungen um Stamm- oder Bewegungsdaten handelt, und ordne auch die Daten des Entitätstyps Lastenrad zu. (3 Punkte)

Die Statusmeldungen sind Bewegungsdaten (1 Punkt): Sie entstehen laufend im Betrieb, beziehen sich auf einen Zeitpunkt und kommen ständig neu hinzu (1 Punkt).
Die Daten des Lastenrads (Rahmennummer, Modell) sind Stammdaten (1 Punkt): Sie bleiben lange gültig und ändern sich nur selten.

d) Für die Umsetzung soll das ER-Modell aus b) in ein relationales Datenmodell überführt werden. Stelle zwei Schritte dar, die dafür notwendig sind, und nutze Beispiele aus dem Modell. (4 Punkte)

Je Schritt 2 Punkte (1 Punkt Schritt, 1 Punkt passendes Beispiel), z. B.:

Entitätstypen werden zu Tabellen (Relationen): Aus Lastenrad wird die Tabelle Lastenrad mit den Attributen als Spalten; der Schlüssel wird Primärschlüssel, Datentypen werden festgelegt.
1:n-Beziehungen werden über einen Fremdschlüssel auf der n-Seite umgesetzt: Die Tabelle Buchung erhält die Spalte Rad-ID als Fremdschlüssel auf Lastenrad.
m:n-Beziehungen werden zu einer eigenen Tabelle (Zwischentabelle) mit den Primärschlüsseln beider Seiten als Fremdschlüssel; Attribute der Beziehung (von, bis) kommen in diese Tabelle (z. B. wenn die Stationierung als m:n-Beziehung modelliert wurde).
1:1- bzw. 1:c-Beziehungen: Fremdschlüssel auf einer Seite, als eindeutig gekennzeichnet (Schloss-ID in Lastenrad mit UNIQUE).

e) Cem Sarıkaya überlegt, künftig die Statusmeldungen der rund 500 Leihräder der Privatkundschaft jede Sekunde zu speichern und auszuwerten. Triff eine begründete Aussage, ob ein relationales Datenmodell dafür geeignet ist. (3 Punkte)

Beispiel (1 Punkt Aussage, 2 Punkte Begründung): Bei 500 Rädern und einer Meldung je Sekunde fallen 500 · 86 400 = 43 200 000 Datensätze pro Tag an. Die Daten kommen sehr schnell (velocity), in großer Menge (volume) und werden fast nur angehängt und zeitlich ausgewertet. Ein klassisches relationales Modell mit vielen Beziehungen und Normalisierung ist dafür nur eingeschränkt geeignet; besser passen spezialisierte Zeitreihen- oder NoSQL-Datenbanken, die viele Schreibzugriffe verteilt verarbeiten. Die Stammdaten (Räder, Kundschaft, Buchungen) können weiterhin relational gespeichert werden.

Auch die begründete Gegenposition ist richtig, z. B.: Die Messwerte sind gleichartig strukturiert; ein relationales DBMS mit Partitionierung nach Zeit, wenigen Indizes und regelmäßiger Verdichtung älterer Werte kann diese Menge noch bewältigen.

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 zum Entity-Relationship-Modell” von oer-informatik.de (H. Stein), Lizenz: CC BY 4.0. Der Artikel wurde unter https://oer-informatik.de/erm-uebungsaufgaben veröffentlicht, die Quelltexte sind in weiterverarbeitbarer Form verfügbar im Repository unter https://gitlab.com/oer-informatik/db-design/entity-relationship-model. Erstellt mit KI-Assistenz; von mir umfassend redaktionell überarbeitet, geprüft und freigegeben. Stand: 26.10.2026.

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

Übungsaufgaben zum Entity-Relationship-Modell