SQL Basic Kurs
Von Elyndra Valen, Senior Entwicklerin bei Java Fleet Systems Consulting
🗺️ Deine Position im Kurs
| Tag | Thema | Status |
|---|---|---|
| 1 | Warum Datenbanken? | ✅ Abgeschlossen |
| 2 | Das relationale Modell | ✅ Abgeschlossen |
| → 3 | Schlüssel & Beziehungen | 👉 DU BIST HIER! |
| 4 | Tabellen erstellen & Daten pflegen | 🔜 Kommt als nächstes |
| 5 | SELECT – Deine erste Abfrage | 🔒 Noch nicht freigeschaltet |
| 6 | Filtern und Sortieren | 🔒 Noch nicht freigeschaltet |
| 7 | Gruppieren und Auswerten | 🔒 Noch nicht freigeschaltet |
| 8 | JOINs – Tabellen verbinden | 🔒 Noch nicht freigeschaltet |
| 9 | Views und Ausblick | 🔒 Noch nicht freigeschaltet |
| 10 | Zusammenfassung & Projekt | 🔒 Noch nicht freigeschaltet |
Modul: SQL Basic
Gesamt-Dauer: 10 Kurstage
Dein Ziel: Verstehen, wie Tabellen durch Schlüssel miteinander verbunden sind
📋 Voraussetzungen für diesen Tag
Du brauchst:
- ✅ Tag 1 & 2 abgeschlossen
- ✅ Du weißt, was Tabellen, Zeilen und Spalten sind
- ✅ XAMPP läuft, phpMyAdmin ist offen
- ✅ Die
adressen-Datenbank ist importiert (vom Dozenten verteilt)
Zur Erinnerung – die adressen-Datenbank:
| Tabelle | Spalten | Inhalt |
|---|---|---|
person | PERSID, AGE, FIRSTNAME, LASTNAME | ~600 Personen |
adressen | ADRESID, stadt, STREET, PERSID | ~1500 Adressen |
Eine Person kann mehrere Adressen haben – genau das schauen wir uns heute genauer an!
Fragen?
Schreib uns: elyndra.valen@java-developer.online
🔄 Kurzwiederholung: Lösung der Challenge von Tag 2
Erinnerst du dich an die Monster-Tabelle von gestern?
| BestNr | Kunde | Adresse | Produkt | Preis | Menge | Produkt2 | Preis2 | Menge2 |
|---|---|---|---|---|---|---|---|---|
| 1 | Müller | Berlin | Laptop | 999 | 1 | Maus | 29 | 2 |
| 2 | Müller | Berlin | Tastatur | 79 | 1 | |||
| 3 | Schmidt | Köln | Maus | 29 | 1 | Kabel | 15 | 3 |
Hier die Lösungen:
1. Welche Daten wiederholen sich unnötig?
- „Müller“ und „Berlin“ stehen zweimal
- „Maus“ und „29“ stehen zweimal
- Das ist Redundanz!
2. Was passiert, wenn Herr Müller nach Köln umzieht?
- Du musst BEIDE Zeilen ändern (Zeile 1 und 2)
- Vergisst du eine, hast du widersprüchliche Daten
3. Was passiert, wenn jemand 5 Produkte bestellt?
- Du bräuchtest: Produkt3, Preis3, Menge3, Produkt4, Preis4, Menge4, Produkt5, Preis5, Menge5
- Die Tabelle wird immer breiter – unpraktisch!
- Und was, wenn jemand 10 Produkte bestellt?
4. In welche Tabellen würdest du aufteilen?
kunden(Kunde, Adresse)produkte(Produkt, Preis)bestellungen(BestellNr, welcher Kunde)positionen(welche Bestellung, welches Produkt, Menge)
Genau so ist unsere versandhandel-Datenbank aufgebaut!
⚡ Das Wichtigste in 30 Sekunden
Heute lernst du:
- ✅ Was ein Primärschlüssel ist (der „Ausweis“ jeder Zeile)
- ✅ Was ein Fremdschlüssel ist (der „Verweis“ auf andere Tabellen)
- ✅ Wie Tabellen miteinander verbunden werden
- ✅ Warum die Datenbank uns vor Fehlern schützt
Am Ende des Tages kannst du: In einer Datenbank erkennen, welche Tabellen wie zusammenhängen.
Schwierigkeitsgrad: 🟢 Einsteiger (aber wichtig!)
Hi! 👋
Willkommen zu Tag 3 – dem Aha-Moment-Tag!
Gestern hast du gesehen, dass Daten auf mehrere Tabellen aufgeteilt werden. Heute lernst du, wie diese Tabellen verbunden sind.
Das Zauberwort heißt: Schlüssel.
Stell dir vor, jede Zeile hat einen Ausweis (Primärschlüssel). Und wenn eine Tabelle auf eine andere verweisen will, merkt sie sich die Ausweisnummer (Fremdschlüssel).
Klingt abstrakt? Wird gleich super konkret. Versprochen!
Los geht’s! 🚀
🟢 GRUNDLAGEN: Was sind Schlüssel?
Der Primärschlüssel – Der Ausweis
Jede Zeile in einer Tabelle braucht etwas, das sie eindeutig identifiziert.
Alltagsvergleich:
- Du hast einen Personalausweis mit einer eindeutigen Nummer
- Kein anderer Mensch in Deutschland hat dieselbe Nummer
- Anhand dieser Nummer kann man dich zweifelsfrei identifizieren
In einer Datenbank ist das der Primärschlüssel (Primary Key, kurz: PK).
Beispiel: Tabelle kunden
| kunden_id | name | vorname | stadt |
|---|---|---|---|
| 1 | Müller | Anna | Berlin |
| 2 | Schmidt | Thomas | Hamburg |
| 3 | Weber | Lisa | München |
Die Spalte kunden_id ist der Primärschlüssel:
- Jede Nummer kommt nur EINMAL vor
- Anhand der Nummer kann man jeden Kunden eindeutig finden
- „Kunde 2“ ist immer Thomas Schmidt – ohne Verwechslungsgefahr
Warum nicht den Namen als Schlüssel?
- Es könnte zwei „Anna Müller“ geben
- Namen können sich ändern (Heirat)
- Eine Nummer ist eindeutig und ändert sich nie
Natürliche vs. Künstliche Schlüssel
„Aber ich habe doch schon eine Email-Adresse – warum brauche ich noch eine extra ID?“
Gute Frage! Es gibt zwei Arten von Schlüsseln:
Natürliche Schlüssel – Werte, die schon in den Daten existieren:
| Beispiel | Klingt gut, weil… | Problem |
|---|---|---|
| Email-Adresse | Jeder hat eine | Leute wechseln ihre Email! |
| Telefonnummer | Scheint eindeutig | Nummern werden recycelt, Leute wechseln Anbieter |
| Sozialversicherungs-Nr. | Wirklich eindeutig | Nicht jeder hat eine (Ausländer, Kinder) |
| Personalausweis-Nr. | Staatlich vergeben | Läuft ab → neue Nummer bei Verlängerung |
| IBAN | Eindeutig pro Konto | Konto kann gewechselt werden |
| Steuernummer | Eindeutig | Kann sich bei Umzug ändern |
Das Kernproblem: Was passiert, wenn sich der „natürliche Schlüssel“ ändert?
Beispiel: Du nutzt Email als Primärschlüssel:
- Kunde hat 500 Bestellungen mit
kunde@alteemail.de - Kunde wechselt zu
kunde@neueemail.de - Du musst ALLE 500 Bestellungen ändern! 😱
Künstliche Schlüssel (auch „Surrogate Keys“) sind extra erzeugte Werte:
kunden_id INT AUTO_INCREMENT PRIMARY KEY
- Die Datenbank vergibt automatisch 1, 2, 3, 4…
- Ändert sich nie
- Hat keine „Bedeutung“ außerhalb der Datenbank
- Ist kurz und schnell zu vergleichen
Best Practice: Nutze künstliche Schlüssel als Primärschlüssel. Speichere natürliche Identifikatoren als normale Spalten:
CREATE TABLE kunden (
kunden_id INT AUTO_INCREMENT PRIMARY KEY, -- künstlicher Schlüssel
email VARCHAR(255) UNIQUE, -- natürlich, aber änderbar
versicherungsnr VARCHAR(20) UNIQUE, -- natürlich, aber optional
telefon VARCHAR(20) -- natürlich, nicht eindeutig
);
Das UNIQUE bei Email und Versicherungsnummer bedeutet: „Darf nur einmal vorkommen“ – aber es ist NICHT der Primärschlüssel. So kannst du die Email ändern, ohne alle Verknüpfungen zu zerstören.
Die 3 Regeln für Primärschlüssel
- Eindeutig: Jeder Wert darf nur einmal vorkommen
- Nicht leer: Jede Zeile MUSS einen Primärschlüssel haben
- Unveränderlich: Der Wert sollte sich nie ändern
Der Fremdschlüssel – Der Verweis
Jetzt wird’s spannend: Wie verbinden wir Tabellen?
Situation: Wir haben eine Bestellung. Wir wollen wissen, welcher Kunde bestellt hat.
Lösung: Wir speichern die kunden_id in der Bestellungs-Tabelle!
Tabelle bestellungen:
| bestellungen_id | kunden_id | datum |
|---|---|---|
| 101 | 1 | 2024-03-15 |
| 102 | 1 | 2024-03-20 |
| 103 | 2 | 2024-03-18 |
Die Spalte kunden_id in der Tabelle bestellungen ist ein Fremdschlüssel (Foreign Key, kurz: FK).
Was sagt uns das?
- Bestellung 101 gehört zu Kunde 1 (Anna Müller)
- Bestellung 102 gehört auch zu Kunde 1 (Anna Müller hat zweimal bestellt!)
- Bestellung 103 gehört zu Kunde 2 (Thomas Schmidt)
Der Fremdschlüssel zeigt auf den Primärschlüssel einer anderen Tabelle.
Die Verbindung visualisiert
Der Pfeil zeigt: „Dieser Fremdschlüssel verweist auf diesen Primärschlüssel.“
🟡 PROFESSIONALS: Schlüssel in der versandhandel-Datenbank
Alle Schlüssel auf einen Blick
| Tabelle | Primärschlüssel | Fremdschlüssel | Verweist auf |
|---|---|---|---|
kunden | kunden_id | – | – |
produkte | produkte_id | – | – |
bestellungen | bestellungen_id | kunden_id | kunden.kunden_id |
positionen | positionen_id | bestellungen_id | bestellungen.bestellungen_id |
positionen | – | produkt_id | produkte.produkte_id |
lieferungen | lieferungen_id | bestellungen_id | bestellungen.bestellungen_id |
Die Beziehungskette
Stell dir vor, du willst wissen: „Welche Produkte hat Anna Müller bestellt?“
Du musst der Kette folgen:
kunden (Anna Müller, ID: 1)
↓
bestellungen (Bestellung 101, kunden_id: 1)
↓
positionen (Bestellung 101, Produkt 5)
↓
produkte (Produkt 5: Laptop)
Das ist die Macht der Schlüssel: Du kannst von jeder Tabelle zu jeder anderen „springen“!
Referenzielle Integrität – Der Bodyguard
Die Datenbank passt auf, dass keine „kaputten“ Verweise entstehen.
Beispiel: Was passiert, wenn du Kunde 1 löschen willst?
Kunde 1 hat Bestellungen (101 und 102). Diese Bestellungen verweisen auf Kunde 1.
Wenn du Kunde 1 löschst, würden die Bestellungen auf einen Kunden verweisen, der nicht mehr existiert. Das wäre ein „verwaister“ Verweis – Chaos!
Die Datenbank verhindert das:
FEHLER: Kann Kunde nicht löschen - es existieren noch Bestellungen!
Das nennt man referenzielle Integrität. Die Datenbank schützt dich vor inkonsistenten Daten.
Was passiert beim Löschen? – Die Optionen
Wenn du versuchst, einen Datensatz zu löschen, auf den andere verweisen, gibt es verschiedene Möglichkeiten:
| Option | Was passiert | Beispiel |
|---|---|---|
| RESTRICT | Löschen wird verhindert | „Kann Kunde nicht löschen – Bestellungen existieren“ |
| CASCADE | Alles Verknüpfte wird mitgelöscht | Kunde löschen → alle seine Bestellungen auch weg |
| SET NULL | Fremdschlüssel wird auf „leer“ gesetzt | Bestellung bleibt, aber kunden_id wird leer |
In der Praxis: Meist wird RESTRICT oder CASCADE verwendet. CASCADE ist praktisch, aber gefährlich – ein Klick kann viele Daten löschen!
🔧 PRAXIS-HÄPPCHEN: Zwei Tabellen verbinden
Jetzt wird’s praktisch! Du hast gestern gelernt, wie man mit LIKE Daten filtert:
SELECT * FROM person WHERE FIRSTNAME LIKE 'Br%';
Das zeigt alle Personen, deren Vorname mit „Br“ anfängt (Bruno, Brian, Brigitte…).
Aber: Die Adressen stehen in einer anderen Tabelle! Wie kommen wir an beides?
Die Verbindung herstellen
Schau dir die beiden Tabellen an:
person:
| PERSID | FIRSTNAME | LASTNAME |
|---|---|---|
| 1 | Bruno | Hoffmann |
| 2 | Roman | Rabenstein |
adressen:
| ADRESID | stadt | STREET | PERSID |
|---|---|---|---|
| 1 | Neu Yannik | Röntgenstr. 32c | 1 |
| 2 | Ricoscheid | Dr.-August-Blank-Str. 82 | 1 |
| 8 | Kleebergdorf | Kölner Gasse 44a | 2 |
Siehst du? Die PERSID verbindet die Tabellen! Bruno (PERSID 1) hat zwei Adressen, Roman (PERSID 2) hat eine.
Zwei Tabellen abfragen – ganz einfach
SELECT * FROM person, adressen WHERE person.PERSID = adressen.PERSID;
Was passiert hier?
FROM person, adressen– wir fragen BEIDE Tabellen abWHERE person.PERSID = adressen.PERSID– aber nur, wo die PERSID übereinstimmt
Probier es aus! Du bekommst alle Personen MIT ihren Adressen.
Noch gezielter: Nur bestimmte Spalten
SELECT person.FIRSTNAME, person.LASTNAME, adressen.stadt, adressen.STREET FROM person, adressen WHERE person.PERSID = adressen.PERSID;
Das zeigt nur Vorname, Nachname, Stadt und Straße – übersichtlicher!
Kombiniert mit LIKE
SELECT person.FIRSTNAME, person.LASTNAME, adressen.stadt FROM person, adressen WHERE person.PERSID = adressen.PERSID AND person.FIRSTNAME LIKE 'Br%';
Jetzt siehst du alle Personen mit „Br“-Vornamen UND ihre Adressen!
Das ist dein erster „JOIN“ – auch wenn wir das Wort noch nicht benutzt haben. Am Tag 8 lernst du die offizielle JOIN-Syntax, aber das Prinzip ist genau das gleiche: Tabellen über gemeinsame Schlüssel verbinden.
🔵 BONUS: Verschiedene Beziehungstypen
Optional: Dieser Teil ist für Neugierige.
1:n – Die häufigste Beziehung
„Ein Kunde kann viele Bestellungen haben.“
- 1 Kunde → n Bestellungen
- Der Fremdschlüssel ist auf der „viele“-Seite (in
bestellungen)
n:m – Die komplexe Beziehung
„Eine Bestellung kann viele Produkte enthalten, und ein Produkt kann in vielen Bestellungen sein.“
Das geht nicht direkt! Dafür braucht man eine Zwischentabelle.
Bei uns: Die Tabelle positionen verbindet bestellungen und produkte.
bestellungen ←── positionen ──→ produkte
1:n n:1
1:1 – Die seltene Beziehung
„Jeder Mitarbeiter hat genau einen Parkplatz, jeder Parkplatz gehört genau einem Mitarbeiter.“
Kommt selten vor – oft kann man das in einer Tabelle lösen.
💬 Real Talk: Die Kursplanung für Tag 3
Java Fleet Büro, Schulungsraum. Das Team sitzt zusammen, um den dritten Kurstag zu besprechen. Am Tisch: Franz-Martin, Elyndra, Nova, Kat und Tom.
Franz-Martin: „Okay, Tag 3. Schlüssel und Beziehungen. Das ist der wichtigste Theorietag.“
Tom: „Ich erinner mich an mein erstes Semester. Primärschlüssel, Fremdschlüssel – das hat bei mir ewig gedauert, bis es klick gemacht hat.“
Kat: „Bei mir war’s der Ausweis-Vergleich. Jede Person hat einen eindeutigen Ausweis, und wenn du auf jemanden verweisen willst, merkst du dir die Ausweisnummer.“
Nova: „Das ist gut! Einfach und konkret.“
Elyndra: „Genau so machen wir’s. Primärschlüssel ist der Ausweis, Fremdschlüssel ist der Verweis auf den Ausweis einer anderen Tabelle.“
Franz-Martin: „Und die referenzielle Integrität?“
Tom: „Das ist der Bodyguard. Die Datenbank passt auf, dass keine kaputten Verweise entstehen.“
Kat: „Aber wir sollten auch was Praktisches einbauen. Die Leute haben gestern LIKE gelernt. Können wir darauf aufbauen?“
Elyndra: „Gute Idee. Wir zeigen, wie man zwei Tabellen verbindet. Ohne das Wort JOIN zu benutzen – einfach über WHERE.“
Nova: „SELECT FROM person, adressen WHERE die IDs gleich sind?“
Elyndra: „Genau. Das ist der einfachste Einstieg. Den richtigen JOIN machen wir später.“
Franz-Martin: „Also: Theorie zu Schlüsseln, Alltagsvergleiche, und als praktisches Häppchen die erste Tabellenverbindung.“
Kat: „Kleine Schritte. Die merken gar nicht, wie viel sie schon können.“
Elyndra: „Das ist der Plan.“
✅ Checkpoint: Hast du es verstanden?
Bevor du weitermachst, teste dein Wissen:
Quiz:
Frage 1: Was ist die Aufgabe eines Primärschlüssels?
Frage 2: Was ist ein Fremdschlüssel und worauf verweist er?
Frage 3: In der Tabelle bestellungen gibt es die Spalte kunden_id. Ist das ein Primärschlüssel oder ein Fremdschlüssel? Warum?
Frage 4: Warum kann ein Name (z.B. „Anna Müller“) kein guter Primärschlüssel sein?
Frage 5: Was bedeutet „referenzielle Integrität“?
Mini-Challenge:
Aufgabe:
Arbeite mit der adressen-Datenbank in phpMyAdmin:
- Finde heraus: Was ist der Primärschlüssel der Tabelle
person? Was ist der Primärschlüssel der Tabelleadressen? - Schreibe eine Abfrage: Zeige alle Personen mit ihren Adressen an, die in einer Stadt wohnen, die mit „Bad“ anfängt. Tipp: Kombiniere die Zwei-Tabellen-Abfrage mit LIKE
- Zähle: Wie viele Adressen hat die Person mit PERSID = 1? (Schau in der adressen-Tabelle nach)
- Überlege: Warum kann eine Person mehrere Adressen haben, aber jede Adresse gehört nur zu einer Person?
Lösung:
Wir besprechen die Lösung am Anfang von Tag 4!
❓ Häufig gestellte Fragen
Frage 1: Muss der Primärschlüssel immer eine Zahl sein?
Nein, aber meistens ist es so. Zahlen sind schnell zu vergleichen und brauchen wenig Speicherplatz. Technisch könnte auch ein Text ein Primärschlüssel sein (z.B. eine ISBN für Bücher), aber Zahlen sind praktischer.
Frage 2: Kann eine Tabelle mehrere Fremdschlüssel haben?
Ja! Die Tabelle positionen hat sogar zwei: bestellungen_id (verweist auf bestellungen) und produkt_id (verweist auf produkte).
Frage 3: Was ist, wenn ich einen Kunden wirklich löschen muss?
Du hast Optionen: Entweder erst alle Bestellungen löschen (CASCADE), oder die Bestellungen behalten aber die Kundenreferenz entfernen (SET NULL), oder – am saubersten – den Kunden als „inaktiv“ markieren statt zu löschen.
Frage 4: Woher weiß ich, welche Spalte der Primärschlüssel ist?
Konvention: Oft heißt sie id oder tabellenname_id (z.B. kunden_id). In der Tabellendefinition ist sie als PRIMARY KEY markiert. Das siehst du, wenn wir morgen Tabellen erstellen!
Frage 5: Kann eine Zeile auf sich selbst verweisen?
Ja, das nennt man „Selbstreferenz“. Beispiel: Eine Tabelle mitarbeiter mit einer Spalte chef_id, die auf einen anderen Mitarbeiter verweist. Kommt vor, ist aber fortgeschritten.
Frage 6: Was passiert, wenn ich einen ungültigen Fremdschlüssel eintrage?
Die Datenbank verhindert das! Wenn du eine Bestellung mit kunden_id: 999 anlegst, aber kein Kunde mit ID 999 existiert, bekommst du einen Fehler.
Frage 7: Nova meinte, Primärschlüssel seien „lowkey das Wichtigste in Datenbanken“. Stimmt das?
Real talk: Ja, ziemlich. Ohne Primärschlüssel keine eindeutige Identifikation. Ohne Fremdschlüssel keine Verbindungen zwischen Tabellen. Das ganze relationale Modell basiert auf diesem Konzept. Also ja – Schlüssel sind fundamental. Ohne sie wäre eine Datenbank nur ein Haufen unverbundener Listen.
📚 Quiz-Lösungen
Hier sind die Antworten zum Quiz von oben:
Frage 1: Was ist die Aufgabe eines Primärschlüssels?
Antwort:
Der Primärschlüssel identifiziert jede Zeile eindeutig.
Wie ein Personalausweis: Jede Zeile hat eine einzigartige „Nummer“, anhand derer man sie zweifelsfrei finden kann. Es gibt keine zwei Zeilen mit demselben Primärschlüssel.
Frage 2: Was ist ein Fremdschlüssel und worauf verweist er?
Antwort:
Ein Fremdschlüssel ist eine Spalte, die auf den Primärschlüssel einer anderen Tabelle verweist.
Er stellt die Verbindung zwischen zwei Tabellen her. Beispiel: kunden_id in der Tabelle bestellungen verweist auf kunden_id in der Tabelle kunden.
Frage 3: In der Tabelle bestellungen gibt es die Spalte kunden_id. Ist das ein Primärschlüssel oder ein Fremdschlüssel? Warum?
Antwort:
Es ist ein Fremdschlüssel.
Begründung: Die Spalte verweist auf die Tabelle kunden. Der Primärschlüssel der Tabelle bestellungen ist bestellungen_id, nicht kunden_id.
Eine Spalte kann nicht gleichzeitig Primär- und Fremdschlüssel derselben Tabelle sein (aber sie kann in ihrer eigenen Tabelle Primärschlüssel sein und in einer anderen als Fremdschlüssel verwendet werden).
Frage 4: Warum kann ein Name (z.B. „Anna Müller“) kein guter Primärschlüssel sein?
Antwort:
Drei Gründe:
- Nicht eindeutig: Es könnte mehrere Personen mit dem Namen „Anna Müller“ geben
- Veränderlich: Namen können sich ändern (z.B. durch Heirat)
- Fehleranfällig: Tippfehler bei Namen sind häufig („Müller“ vs. „Mueller“)
Eine automatisch generierte Nummer ist eindeutig, unveränderlich und nicht tippfehleranfällig.
Frage 5: Was bedeutet „referenzielle Integrität“?
Antwort:
Referenzielle Integrität bedeutet, dass alle Verweise (Fremdschlüssel) auf gültige Datensätze zeigen.
Die Datenbank stellt sicher, dass keine „verwaisten“ Verweise entstehen. Beispiel: Du kannst keinen Kunden löschen, solange noch Bestellungen auf ihn verweisen.
Das schützt vor inkonsistenten Daten.
🎉 Tag 3 geschafft!
Yes! Du hast den Aha-Moment-Tag gemeistert! 🚀
Das hast du heute gelernt:
- ✅ Primärschlüssel = der eindeutige „Ausweis“ jeder Zeile
- ✅ Fremdschlüssel = der Verweis auf andere Tabellen
- ✅ Wie Tabellen durch Schlüssel verbunden sind
- ✅ Referenzielle Integrität schützt vor Datenchaos
Du verstehst jetzt: Das Herzstück relationaler Datenbanken – wie Tabellen zusammenhängen und warum das System dich vor Fehlern schützt.
Honestly? Wenn du Primär- und Fremdschlüssel verstanden hast, hast du das wichtigste Konzept relationaler Datenbanken begriffen. Ab morgen wird’s praktisch! 💪
Wie geht’s weiter?
Morgen (Tag 4): Tabellen erstellen & Daten pflegen (DDL & DML)
Was dich erwartet:
- Dein erster SQL-Befehl! 🎉
- CREATE TABLE – eine Tabelle erstellen
- INSERT – Daten einfügen
- UPDATE – Daten ändern
- DELETE – Daten löschen
- Ab morgen tippst du echtes SQL! 🔥
Brauchst du eine Pause?
Gönn sie dir! Die letzten drei Tage waren viel Theorie. Ab morgen geht’s in die Praxis.
Tipp für heute:
Schau dir nochmal die versandhandel-Tabellen an. Versuche, die Pfeile zwischen den Tabellen in deinem Kopf zu sehen: Welche Fremdschlüssel zeigen auf welche Primärschlüssel?
🛠️ Troubleshooting
Problem: „Ich verwechsle Primär- und Fremdschlüssel.“
Lösung:
- Primärschlüssel = Der Chef in seiner EIGENEN Tabelle (identifiziert die Zeile)
- Fremdschlüssel = Der Gast aus einer ANDEREN Tabelle (verweist auf den Chef dort)
Merkregel: Fremdschlüssel sind „fremd“ – sie gehören eigentlich zu einer anderen Tabelle.
Problem: „Ich verstehe nicht, warum man nicht einfach alles in eine Tabelle packt.“
Lösung: Denk an das Umzug-Beispiel: Wenn ein Kunde umzieht, müsstest du bei einer Monstertabelle jede Bestellung ändern. Mit getrennten Tabellen änderst du nur EINE Zeile in der Kundentabelle.
📖 Im Buch nachlesen
Mehr Details zu den heutigen Themen findest du in:
Kapitel 2: Das relationale Datenmodell
- 2.3 Schlüsseltypen
- 2.3.1 Primärschlüssel
- 2.3.2 Fremdschlüssel
- 2.4 Referenzielle Integrität
Kapitel 3: Datenbankentwurf
- 3.3 Abstraktionskonzepte
- 3.4 Das ER-Modell (Grundlagen)
SQL Ressourcen & Weiterführende Links
Elyndra’s Schatzkiste – Alles, was du für deinen SQL-Lernweg brauchst
🎮 Interaktive Übungsplattformen
Übung macht den Meister. Diese Plattformen lassen dich SQL direkt im Browser ausprobieren – ohne Installation, ohne Risiko.
SQLBolt – Der Klassiker für Einsteiger
- Interaktive Lektionen mit sofortigem Feedback
- Perfekt strukturiert: SELECT → JOINs → Subqueries
- Keine Registrierung nötig
- Empfohlen für: Tag 5-8 unseres Kurses
SQLZoo – Echte Daten, echte Herausforderungen
- Seit über 20 Jahren der Goldstandard
- Übungen mit echten Datensätzen (Nobel-Preise, Fußball-WM, etc.)
- Progressiv schwieriger werdende Aufgaben
- Empfohlen für: Tag 9-10 und danach
W3Schools SQL Tutorial
- „Try it Yourself“ Editor bei jedem Beispiel
- Komplette Referenz aller SQL-Befehle
- Gut zum Nachschlagen
- Empfohlen für: Schnelles Nachschlagen während des Kurses
SQL Easy – Minimalistisch & Effektiv
- Reduziert auf das Wesentliche
- Sofort loslegen ohne Ablenkung
- Über 200.000 Lernende seit 2017
- Empfohlen für: Schnelle Wiederholung
Learn SQL Online
- Komplett kostenlos
- Interaktive Code-Beispiele
- Community-getrieben
- Empfohlen für: Zusätzliche Übungen
📚 Offizielle Dokumentation
Wenn du es genau wissen willst, führt kein Weg an der offiziellen Doku vorbei.
MariaDB Knowledge Base (Deutsch)
- Offizielle Dokumentation auf Deutsch
- Alle Befehle, Datentypen, Konfigurationen
- Das Nachschlagewerk für unseren Kurs
MariaDB.org Documentation
- Hauptdokumentation der MariaDB Foundation
- PDF-Download verfügbar
- Release Notes für alle Versionen
- Kostenlose Video-Kurse zu fortgeschrittenen Themen
MySQL Referenz
- Gilt zu 95% auch für MariaDB
- Sehr detailliert und umfangreich
- Englisch, aber sehr präzise
🛠️ Setup & Installation
Alles, was du brauchst, um SQL auf deinem Rechner zum Laufen zu bringen.
XAMPP – Das Rundum-Sorglos-Paket
- Apache + MariaDB + PHP in einem Paket
- Windows, Mac, Linux
- Unsere Empfehlung für den Kurs!
- Ein Klick → Datenbank läuft
MariaDB Standalone
🔗 mariadb.com/get-started-with-mariadb
- Offizielle Installationsanleitung
- Für alle Betriebssysteme
- Docker-Variante verfügbar
HeidiSQL – Der komfortable Client
- Kostenloser SQL-Client für Windows
- Grafische Oberfläche statt Kommandozeile
- Perfekt für Einsteiger
- Export/Import von Daten
DBeaver – Der Alleskönner
- Universeller Datenbank-Client
- Windows, Mac, Linux
- Unterstützt MySQL, MariaDB, PostgreSQL, Oracle, …
- Community Edition kostenlos
🇩🇪 Tutorials auf Deutsch
Nicht jeder mag englische Tutorials. Hier die besten deutschen Ressourcen.
IONOS Digital Guide
🔗 ionos.de – MySQL/MariaDB installieren
- Schritt-für-Schritt Installationsanleitung
- Screenshots für jeden Schritt
- Linux, Windows, Mac abgedeckt
Guru99 MariaDB Tutorial
🔗 guru99.com/de/mariadb-tutorial-install.html
- Übersetztes Tutorial
- Viele Screenshots
- Grundlagen gut erklärt
GeeksforGeeks SQL Tutorial
🔗 geeksforgeeks.org/sql-tutorial
- Sehr umfangreich
- Von Basics bis Advanced
- Viele Code-Beispiele
🎬 Video-Kurse (kostenlos)
Manchmal ist Zuschauen einfacher als Lesen.
freeCodeCamp – SQL Full Course
- Kompletter SQL-Kurs in einem Video
- 4+ Stunden Inhalt
- Sehr beliebt (Millionen Views)
- Englisch mit guter Aussprache
Bro Code – SQL Playlist
Gut für Pausen zwischendurch
Viral gegangen 2024
Kurze, knackige Videos
Schritt für Schritt
💬 Feedback?
War dieser Tag zu schnell? Zu langsam? Hast du den Aha-Moment gehabt?
Schreib uns: feedback@java-developer.online
Wir wollen, dass du erfolgreich lernst!
Bis morgen – dann wird’s praktisch! 👋
Elyndra
SQL Basic – Tag 3 von 10
© Java Fleet Systems Consulting
www.java-developer.online
