Beiträge von DanielIT

Ja, und die Methode ist erstaunlich simpel: Frag die Beziehung aus beiden Richtungen, jeweils mit „ein … – wie viele …?“. Beispiel Kunde/Bestellung:

• Ein Kunde kann wie viele Bestellungen haben? → beliebig viele (n).
• Eine Bestellung gehört zu wie vielen Kunden? → genau einem (1).

Ergebnis: 1:n. Das machst du immer für beide Seiten einzeln – die zwei Antworten zusammen ergeben die Kardinalität. Bei „viele zu viele“ in beide Richtungen (z. B. Student ↔ Veranstaltung) hast du ein n:m.

Eine Eselsbrücke, die bei mir hängen geblieben ist: Der Primärschlüssel ist der Ausweis einer Zeile in ihrer eigenen Tabelle (eindeutig, nie leer). Der Fremdschlüssel ist eine Kopie dieses Ausweises in einer anderen Tabelle und sagt „ich gehöre zu genau diesem Datensatz dort drüben“. Genau deshalb sichert der Fremdschlüssel die referenzielle Integrität – die Datenbank lässt keinen Fremdschlüssel zu, zu dem es keinen passenden Primärschlüssel gibt. Das verhindert „verwaiste“ Datensätze.

Gern, am Beispiel klickt es sofort 🙂 Nimm zwei Tabellen, Kunde und Bestellung:

• Primärschlüssel (PK): identifiziert eine Zeile eindeutig innerhalb ihrer eigenen Tabelle. In Kunde ist das die KundenID. Jeder Kunde hat genau eine, sie ist nie leer und nie doppelt.
• Fremdschlüssel (FK): ist ein Feld in einer anderen Tabelle, das auf einen Primärschlüssel verweist. In Bestellung steht eine KundenID als FK – sie sagt, zu welchem Kunden die Bestellung gehört.

Kurz: Der PK identifiziert (wer bin ich?), der FK verknüpft (zu wem gehöre ich?). Über genau dieses Paar machst du später deinen JOIN.

Was ich am neuen Format spannend finde: die schiere Datenmenge 🤓 So viele Teams und Spiele – da juckt es mich in den Fingern, mal auszuwerten, welche Tipp-Strategie im Forum am besten abschneidet. Vielleicht baue ich am Ende eine kleine Auswertung, wer am konstantesten getippt hat. Bis dahin: fleißig weiter tippen, Leute!

Anna hat das Warum erklärt, hier das Wie konkret. Du baust eine Zuordnungstabelle (oft „belegt“ oder Student_Modul):

• Spalte 1: StudentID (FK auf Student)
• Spalte 2: ModulID (FK auf Modul)

Jede Zeile = genau eine Belegung. Student 5 in Modul 3 → eine Zeile (5, 3). Belegt Student 5 noch Modul 7 → zweite Zeile (5, 7). Der zusammengesetzte Primärschlüssel aus beiden Spalten verhindert, dass dieselbe Belegung doppelt drinsteht. Aus einem n:m werden so technisch zwei 1:n-Beziehungen.

Zu den Konnektoren – die unterscheiden sich nach der Anzahl der Pfade, die ausgelöst werden:

• UND: Alle ausgehenden Pfade werden parallel durchlaufen (z. B. nach 'Bestellung angenommen' gleichzeitig 'Ware kommissionieren' und 'Rechnung erstellen').
• XOR: Genau ein Pfad, sich gegenseitig ausschließend (z. B. 'Bonität ok' oder 'Bonität nicht ok').
• ODER: Mindestens einer, aber auch mehrere Pfade möglich.

Wichtige Gotcha: Nach einem Ereignis darf kein ODER- oder XOR-Konnektor zum Aufspalten stehen, weil ein Ereignis selbst keine Entscheidung treffen kann. Entscheidungen entstehen immer aus einer Funktion heraus.

Das ist völlig normal und kein Fehler. Ein (INNER) JOIN verknüpft jede passende Kombination. Wenn ein Kunde drei Bestellungen hat, erscheint dieser Kunde drei Mal im Ergebnis – einmal pro zugehöriger Bestellung. Die Anzahl der Ergebniszeilen richtet sich also nach der Anzahl der Bestellungen, nicht der Kunden.

Stell es dir so vor: Du fragst nicht 'Liste die Kunden', sondern 'Liste alle Bestellungen mitsamt Kundendaten'. Dass sich die Kundendaten wiederholen, gehört dazu.

Ergänzend zu Tobi: Die Lösung ist Aufteilen in zwei Tabellen entlang der Abhängigkeit.

• Bestellung(BestellNr, KundenNr) – KundenNr wird hier zum Fremdschlüssel.
• Kunde(KundenNr, KundenName, KundenOrt)

Praktischer Vorteil: Wenn ein Kunde umzieht, änderst du den Ort an genau einer Stelle statt in jeder Bestellung. Genau diese Redundanz und die daraus folgenden Update-Anomalien will die Normalisierung verhindern. Wenn du dir bei sowas unsicher bist, frag dich immer: 'Beschreibt das Attribut wirklich den Schlüssel oder ein anderes Objekt?'

Den Anhang sehe ich hier leider nicht (alte Threads verlieren manchmal die Datei). Am schnellsten geht’s, wenn du deine SQL-Statements direkt als Text reinkopierst – dann schauen wir drüber.

Die Klassiker, auf die du achten solltest:

• SELECT/WHERE: Filterbedingung korrekt? Strings in Anführungszeichen, Zahlen ohne.
• JOIN: immer eine ON-Bedingung (Fremdschlüssel = Primärschlüssel), sonst Kreuzprodukt.
• GROUP BY: alle nicht-aggregierten Spalten aus dem SELECT müssen ins GROUP BY.
• Aggregatfunktionen (COUNT, SUM, AVG) nicht in WHERE, sondern in HAVING filtern.

Poste die Aufgabenstellung + deine Lösung als Text, dann korrigiere ich dir das gern Zeile für Zeile. 👍

Das ist ein typischer Stolperstein: Unter „Sendungen“ sind die meisten Schaltflächen ausgegraut, bis du den Seriendruck tatsächlich startest. Vorgehen:

1. Sendungen → Seriendruck starten → Dokumenttyp wählen (z.B. „Briefe“).
2. Empfänger auswählen → Datenquelle verknüpfen (vorhandene Liste/Excel oder neue Adressliste anlegen).
3. Erst danach werden Seriendruckfeld einfügen, „Vorschau Ergebnisse“ usw. aktiv.

Ohne verknüpfte Datenquelle bleibt fast alles grau – das ist kein Fehler, sondern die Reihenfolge. Du brauchst auch keine „echten“ Daten, eine kleine Test-Adressliste reicht zum Nachvollziehen. Damit sollten die Aufgaben lösbar sein 👍