Datenbank-Dōjō

Prüfungsvorbereitung Datenbanken · alles, was du für Montag brauchst
Prüfung: Montag
{{ gesamtLabel }}
gelernt
Dein Lernfortschritt

Du hast {{ doneCount }} von {{ totalCount }} Lernzielen geschafft. Arbeite die Module durch – jede richtig beantwortete Frage, jede gewusste Karteikarte und jede gelöste Übung zählt.

gelernt offen

Themen

6 Module · klicke zum Öffnen
SQL-Dōjō öffnen →
Echte SQL-Engine: Befehle eintippen, ausführen, mit Sofort-Feedback üben (eigene Seite)

Dein Fortschritt wird automatisch in diesem Browser gespeichert · Inhalte aus deinen Prüfungsunterlagen (SBSZ Bamberg · TSM01A)

MODUL {{ am.nr }}

{{ am.titel }}

{{ modPctLabel }}
gelernt

Wähle pro Frage eine Antwort. Du bekommst sofort Rückmeldung mit Begründung. Richtig beantwortete Fragen zählen zu deinem Fortschritt.

{{ q.nr }}
{{ q.frage }}
{{ q.fbIcon }}
{{ q.fbTitel }} {{ q.erklaerung }}

Tippe auf eine Karte, um die Antwort zu sehen. Markiere „Gewusst", was du sicher kannst – das zählt zu deinem Fortschritt.

{{ c.front }}
↻ umdrehen
{{ c.back }}

Die Wissenspyramide zeigt, wie aus rohen Zeichen Schritt für Schritt nutzbares Wissen wird. Jede Ebene fügt etwas hinzu.

Wissen
Information + Erfahrung + Handlungsregeln
„49 € ist günstig – wir schließen den Vertrag ab."
Information
Daten + Bedeutung / Kontext
„Der Preis beträgt 49 Euro."
Daten
geordnete Zeichen, strukturiert & messbar
PREIS49
Zeichen
kleinste Elemente: Buchstaben & Ziffern
P, R, E, I, S, 4, 9
Merksatz
Daten sind reine Syntax (Zeichen). Erst Semantik (Bedeutung) macht daraus Information. Wissen entsteht, wenn Informationen vernetzt und in Wenn-Dann-Regeln handlungsfähig werden.

Datengestützter Entscheidungsprozess

Erst aufbereiten, dann entscheiden. Wer aus Rohdaten direkt handelt, überspringt die Analyse – ein häufiger Fehler.

1
Datenerfassung
2
Aufbereitung / Analyse
3
Entscheidung
4
Umsetzung
5
Erfolgskontrolle

Wenn du das sicher kannst, mach das Quiz und die Karteikarten dieses Moduls – dann steigt dein Fortschritt.

Ein Entity-Relationship-Modell (ERM) bildet die reale Welt als Entitäten, ihre Attribute und ihre Beziehungen ab – die Grundlage jeder Datenbank.

Entität
Ein Objekt der realen Welt, z. B. KUNDE, PROJEKT, ROBOTERTYP.
Attribut
Eine Eigenschaft einer Entität, z. B. Name, Matrikel-Nr., Preis.
Beziehung
Verbindet Entitäten, z. B. „Kunde hat Auftrag". Mit Kardinalität.

Kardinalitäten

1:1Ein A gehört zu genau einem B und umgekehrt. Beispiel: Lehrstuhl ↔ Professor.
1:NEin A hat mehrere B, ein B gehört zu genau einem A. Beispiel: Kunde (1) → Aufträge (N).
N:MViele A zu vielen B. Beispiel: Studenten ↔ Vorlesungen. Muss aufgelöst werden!
N:M auflösen — die Zwischentabelle
Student N — Hört_Vorlesung
(Matrikel-Nr., Kurs-Nr.)
— M Vorlesung
Die Verknüpfungstabelle nimmt die Primärschlüssel beider Entitäten als Fremdschlüssel auf. Aus N:M werden zwei 1:N-Beziehungen.

Zwei Notationen — eine Bedeutung

(min,max)-Notation
Zahlenpaar an der Linie. Look-across: Du schaust auf die gegenüberliegende Entität – „wie viele der anderen gehören zu mir?"
Krähenfuß-Notation
Symbole (Kreis, Strich, Fuß). Look-here: Das Symbol steht am Ende der Linie bei der Ziel-Entität. Intuitiv & kompakt – daher in CASE-Tools beliebt.

Probier den Wechsel selbst aus → Tab ER-Explorer.

Stell eine Kardinalität ein und sieh, wie sie in beiden Notationen aussieht und gelesen wird. „Pro Entität A: wie viele B?"

Minimum
Maximum
Entität A Entität B {{ erView.combo }}
Krähenfuß-Symbol am Ende bei Entität B
Krähenfuß heißt
{{ erView.kfName }}
Im Klartext
{{ erView.reading }}

Ein Datenbankmanagementsystem (DBMS) ist die Software zwischen Nutzern und der eigentlichen Datenbank. Es löst genau die Probleme, die bei vielen einzelnen Dateien (z. B. Excel) entstehen.

DBMS statt vieler Excel-Dateien

Gleiche Daten liegen mehrfach in 12 Dateien.
DBMS speichert jede Information nur einmal, zentral.
Redundanz ↓
Zwei Personen ändern dieselbe Datei – Änderungen gehen verloren.
DBMS erlaubt gleichzeitigen sicheren Zugriff.
Mehrbenutzer­betrieb
Datumsformate widersprechen sich zwischen Dateien.
DBMS prüft Daten automatisch beim Speichern.
Datenintegrität

ACID — sichere Transaktionen

A — Atomicity
Alles oder nichts: Eine Transaktion wird ganz oder gar nicht ausgeführt.
C — Consistency
Die Datenbank ist vor und nach der Transaktion in einem gültigen Zustand.
I — Isolation
Gleichzeitige Transaktionen stören sich nicht gegenseitig.
D — Durability
Nach dem „Commit" bleiben Daten erhalten – auch bei Stromausfall/Crash.

Mehrbenutzer & das „Lost Update"

Ohne Locking: Nutzer A und B lesen beide „5 freie Plätze". Beide buchen und speichern „4". Eine Buchung geht unbemerkt verloren – die letzte Speicherung überschreibt die erste.
Lösung — Concurrency Control: Das DBMS sperrt den Datensatz für die Dauer der Buchung (Locking). Der zweite Nutzer kann währenddessen nur lesen, nicht ändern.

So bearbeitet das DBMS eine Anfrage

1
Berechtigung prüfen
2
In Speicher­operationen übersetzen
3
Abfrage optimieren
4
Daten zurücksenden

Bei Big Data stoßen klassische Methoden an Grenzen. Die Herausforderungen beschreibt man mit den 5 V’s.

Volume
schiere Menge
Velocity
Geschwindigkeit
Variety
Vielfalt
Veracity
Verlässlichkeit
Value
Wert/Nutzen
Merke: Sekündliche Live-Daten (GPS, Herzfrequenz) sind vor allem ein Velocity-Problem – es geht um die Geschwindigkeit des Eingangs, nicht die Menge.

Drei Datenarten

Strukturiert
Feste Tabellenspalten mit Datentypen.
→ relationale DB
Semi-strukturiert
Tags/Keys geben Struktur, aber kein starres Schema.
→ JSON, XML
Unstrukturiert
Keine feste Struktur.
→ Text, Bilder, Video

Wenn alles in einer Tabelle steht, entstehen Redundanz (Daten doppelt) und daraus Anomalien. Normalisierung teilt die Daten sinnvoll auf.

ID_MA M_Name Ort ID_Abt Abt_Name
1BauerNürnberg1Vertrieb
2SchmidtBamberg1Vertrieb
3WeberMünchen2IT
„Vertrieb" steht doppelt → Redundanz. Das ist die Wurzel der Anomalien.

Die vier Anomalien

Redundanz
Dieselben Daten mehrfach gespeichert.
Änderungsanomalie
Eine Änderung muss an vielen Stellen gemacht werden – sonst Widerspruch.
Löschanomalie
Beim Löschen gehen ungewollt andere Infos verloren.
Einfügeanomalie
Etwas lässt sich nicht speichern, weil andere Daten fehlen.

Die Lösung: aufteilen

Mitarbeiter
ID_MA, M_Name, M_Vor, Straße, PLZ, Ort, Gehalt, ID_Abt (FK)
Abteilung
ID_Abt, Abt_Name

Unterstrichen = Primärschlüssel. ID_Abt ist in Mitarbeiter der Fremdschlüssel. Jetzt steht „Vertrieb" nur noch einmal. → Üben im Tab Anomalie-Trainer.

Ordne jede Situation der richtigen Anomalie zu. (Tabelle Mitarbeiter_mit_Abteilung mit doppelter Abteilung.)

A  „Vertrieb" wird in „Sales" umbenannt – der Name muss in Datensatz 1 und 2 geändert werden.
B  Neue Abteilung „Marketing" hat noch keine Mitarbeiter und kann nicht eingefügt werden.
C  Die letzten beiden IT-Mitarbeiter werden gelöscht – alle Infos über „IT" gehen verloren.
D  „ID_Abt=1, Vertrieb" steht doppelt in der Tabelle (Datensatz 1 und 2).
{{ r.label }}
{{ r.mark }}
{{ anomMsg }}

SQL teilt sich in drei Bereiche: DDL (Struktur bauen), DML (Daten ändern), DQL (Daten abfragen). Übungstabelle: verkaeufe.

Reihenfolge einer Abfrage — Pflicht
SELECTFROMWHEREGROUP BYHAVINGORDER BYLIMIT
Welche Spalten · woher · welche Zeilen · wie gruppieren · welche Gruppen · wie sortieren · wie viele
Auswählen & Filtern DQL
SELECT produkt, menge FROM verkaeufe;
WHERE region = 'Nord'
WHERE einzelpreis BETWEEN 10 AND 50
WHERE produkt LIKE 'Akku%'
WHERE region IN ('Nord','Süd')
ORDER BY einzelpreis DESC LIMIT 5;
Text in 'Anführungszeichen', Zahlen ohne. % = beliebig viele, _ = genau ein Zeichen.
Aggregieren & Gruppieren
COUNT(*) · SUM(menge) · AVG(einzelpreis)
MIN(...) · MAX(...)

SELECT kategorie, SUM(menge*einzelpreis)
FROM verkaeufe
GROUP BY kategorie
HAVING SUM(menge*einzelpreis) > 5000;
WHERE filtert vor, HAVING nach dem Gruppieren.
Tabellen bauen DDL
CREATE TABLE kunden (
  id INT PRIMARY KEY AUTO_INCREMENT,
  name VARCHAR(50) NOT NULL,
  ort VARCHAR(50) DEFAULT 'Bamberg'
);
ALTER TABLE kunden ADD plz VARCHAR(5);
DROP TABLE kunden;
Daten ändern DML
INSERT INTO kunden (name, ort)
VALUES ('Müller GmbH', 'Bamberg');

UPDATE kunden SET ort='Forchheim'
WHERE id = 1;

DELETE FROM kunden WHERE id = 7;
UPDATE/DELETE ohne WHERE trifft ALLE Zeilen!

Jetzt selbst tippen → Tab SQL-Übung (echte Datenbank im Browser) oder die volle SQL-Dōjō.

Tippe SQL und führe es wirklich aus – gegen dieselbe Tabelle verkaeufe wie in der Dōjō.

Spalten: verkauf_id · produkt · kategorie · region · verkaeufer · verkaufsdatum · menge · einzelpreis
verkaeufe — SQL
{{ sqlStatus }}
⚠ {{ sqlErrorMsg }}
{{ sqlInfoMsg }}
{{ col }}
{{ cell }}
{{ sqlRowInfo }}
Volle SQL-Dōjō →
Gürtelstufen, Lern-/Festigen-/Lücken-Modus & Time-Attack

Prüfungssimulation

{{ mockCount }} gemischte Single-Choice-Fragen aus allen Themen, auf Zeit. Du hast 15 Minuten. Während der Prüfung gibt es kein Sofort-Feedback – die Auswertung mit allen Begründungen kommt am Ende. Wie in echt.

Frage {{ mockPos }} / {{ mockCount }}
{{ mockTimer }}
{{ mockQModul }}
{{ mockFrage }}
{{ mockScorePct }}
{{ mockVerdict }}

Du hast {{ mockCorrect }} von {{ mockCount }} Fragen richtig beantwortet · Zeit: {{ mockUsedTime }}

Auswertung

{{ r.icon }}
{{ r.nr }}. {{ r.frage }}
Deine Antwort: {{ r.yourText }}
Richtig wäre: {{ r.richtigText }}
{{ r.erklaerung }}