Ziel: Saubere Relationen statt redundanter Datensuppe

Access ist kein Excel.
Wenn Du Deine Datenstruktur nicht im Griff hast, wird die Anwendung irgendwann instabil, langsam und widersprüchlich.
Mit richtigen Beziehungen kannst Du das vermeiden – und vieles automatisieren.

Variante 1: Primärschlüssel setzen

Jede Tabelle braucht einen eindeutigen Schlüssel.

• tblKunde → KundenID (Autowert)
• tblAuftrag → AuftragID (Autowert)

Ohne PK kein Join, kein Nachschlagefeld, keine referenzielle Integrität.

👉 Niemals auf Namen, E-Mail oder Kombinationen verlassen.

Variante 2: Fremdschlüssel anlegen

Beziehungen entstehen durch Fremdschlüssel.

• tblAuftrag.KundenID → verweist auf tblKunde.KundenID
• tblArtikel.AuftragID → verweist auf tblAuftrag.AuftragID

In der Beziehungsliste festlegen (Datenbanktools → Beziehungen).

' Beispiel: Beziehung per DAO setzen
Dim rel As DAO.Relation
Set rel = CurrentDb.CreateRelation("r_Auftrag_Kunde", "tblKunde", "tblAuftrag", dbRelationUpdateCascade)
rel.Fields.Append rel.CreateField("KundenID")
rel.Fields("KundenID").ForeignName = "KundenID"
CurrentDb.Relations.Append rel

So kannst Du auch per Code sauber modellieren.

Variante 3: referenzielle Integrität aktivieren

Beim Anlegen der Beziehung:

• „Referenzielle Integrität“ aktivieren
• „Löschen weitergeben“ nur, wenn es wirklich Sinn ergibt

Ergebnis:

• Access verhindert Waisen-Einträge
• automatische Löschung/Kaskadierung bei Bedarf
• besseres Verhalten bei Joins und Formulareinbindungen

Variante 4: Unterformulare mit verknüpften Daten

Wenn die Beziehungen gesetzt sind, kannst Du Unterformulare automatisch binden:

• Hauptformular: frmKunde
• Unterformular: sfrmAuftraege

Verknüpfung:

Me.sfrmAuftraege.LinkMasterFields = "KundenID"
Me.sfrmAuftraege.LinkChildFields = "KundenID"

Funktioniert nur bei sauberer 1:n-Beziehung.

Variante 5: Nachschlagefelder in Tabellen vermeiden

Access erlaubt es, ein Feld direkt als Nachschlagefeld zu definieren.
Sieht gut aus – ist aber schlecht wartbar.

👉 Lieber im Formular machen:

RowSource = "SELECT KundenID, Name FROM tblKunde ORDER BY Name"
BoundColumn = 1
ColumnCount = 2
ColumnWidths = 0cm;5cm

Dann bleibt die Datenstruktur klar – und das UI flexibel.

Variante 6: n:m-Beziehungen mit Zwischentabelle

Beispiel: Kunden können mehrere Produkte haben, Produkte können bei mehreren Kunden sein.

Dazwischen:

• tblKundeProdukt mit KundenID, ProduktID

Primärschlüssel = Kombination beider Felder.
Oder: künstlicher Autowert + Unique Constraint.

CREATE TABLE tblKundeProdukt (
    ID AUTOINCREMENT PRIMARY KEY,
    KundenID LONG,
    ProduktID LONG,
    UNIQUE (KundenID, ProduktID)
)

Variante 7: Beziehungen mit Validierung kombinieren

Wenn ein Eintrag keinen passenden Fremdschlüssel hat, greifst Du hart durch:

If DCount("*", "tblKunde", "KundenID=" & Me.KundenID) = 0 Then
    MsgBox "Kunde existiert nicht.", vbCritical
    Cancel = True
End If

Geht auch für ComboBoxes und Lookup-Felder.

Variante 8: Beziehungen sichtbar dokumentieren

Datenbanktools → Beziehungen
Screenshot exportieren.
Oder per Code alle Beziehungen listen:

Dim rel As DAO.Relation
For Each rel In CurrentDb.Relations
    Debug.Print rel.Name, rel.Table, rel.ForeignTable
Next

Hilft bei Migration, Fehleranalyse oder Doku.

Best Practices

• immer eindeutige PKs (Autowert oder GUID)
• Fremdschlüssel sauber benennen (KundenID, nicht IDKunde)
• keine Redundanz in Tabellen
• keine Lookup-Felder in Tabellen
• 1:n-Beziehungen per Unterformular nutzen
• n:m-Beziehungen mit Zwischentabelle realisieren
• Beziehungen dokumentieren und pflegen

Fazit für Entwickler

Access kann Beziehungen – aber Du musst sie ihm erklären.
Wenn Du sauber modellierst, sparst Du Dir später viele Umwege: weniger Fehler, weniger Duplikate, bessere Formulare.