Beiträge von DanielIT

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 👍