Neuigkeiten:

Ist euer Problem gelöst, dann bitte den Knopf "Thema gelöst" drücken!

Mobiles Hauptmenü

Abfrage: Verknüpfung ändern

Begonnen von Christian72, Heute um 10:55:55

⏪ vorheriges - nächstes ⏩

Christian72

Guten Morgen,
 
meine Datenbank wird verwendet zum Schreiben von Angeboten, Auftragsbestätigungen, Lieferscheinen und Rechnungen für einen kleinen Handel für Messtechnik; habe diesen vor gut einem Jahr vom Vorgänger übernommen.
Jedem Kunden (Tabelle: "Firma") werden Zahlungs- und Lieferbedingungen (Tabelle: "Zahlungsziel-Frachtkosten") zugewiesen.
Verknüpft sind beide Tabellen über das Attribut "Firmasuch". Das hat folgenden Inhalt:
Firmenname + Bindestrich + Ort (der Firma)
Also zum Beispiel:
 - Volkswagen-Wolfsburg
 - Allianz-München
 - Airbus-Hamburg
 
Dieses Attribut soll komplett aus der Datenbank entfernt werden.
Es ist in einer Reihe von Tabellen und Abfragen und Formularen enthalten.
Anfangen möchte ich mit den oben genannten Zahlungsbedingungen. 
Ich habe dazu in der Tabelle "Zahlungsziel-Frachtkosten" ein neues Attribut "firma_id" ergänzt (siehe: Anhang 1) und dieses mit dem Attribut "Schlüssel" in der Tabelle "Firma" verknüpft (siehe: Anhang 2).
Habe gestern anschließend eine Rechnung erzeugt, was (erwartungsgemäß) nicht funktioniert hat.
Als ich bei "firma_id" den "Schlüssel" aus "Firma eingetragen habe, hat es geklappt.
Die nächsten beiden Schritte sollen sein:
 - Löschen der Verknüpfung von "Firmasuch" zu "Firmasuch"
 - Löschen des Attributes "Firmasuch" aus der Tabelle "Zahlungsziel-Frachtkosten"
 
Vorab aber folgende Fragen:
 - Ist die Vorgehensweise insgesamt sinnvoll?
 - Ist der Name des neuen Attributs "firma_id" gut gewählt?
 - Gibt es eine Möglichkeit alle Einträge von "Schlüssel" in der Tabelle "Firma" auf einmal nach "firma_id" in "Zahlungsziel-Frachtkosten zu kopieren?
 
Vielen Dank vorab für eure Antworten!
 
Christian
 

Doming

Moin Christian,
das wird so nicht klappen, denn von selber wird sich Dein Feld firma_id nicht füllen.
Also vorweg, da es sich bei dem Feld um den Primärschlüssel einer anderen Tabelle handelt, würde ich ihn mit dem Präfix FS versehen, also z.B. FS_firmID.
Dann das Feld mit einer Aktualisierungsabfrage füllen, um den Schlüssel aus der Firmentabelle dort einzufügen. Danach kannst Du dann die Beziehung ,,Firmasuch" dort entfernen.

Gibt es einen Grund, warum zwischen den Tabellen keine referentielle Integrität eingestellt ist?
Gruß
 Doming

Bitsqueezer

Hallo Christian,

ja, das "Firmasuch" gegen eine ID auszutauschen, ist auf jeden Fall sinnvoll, da "Name-Ort" kaum wirklich eindeutig ist (was machst Du bei 3 Standorten einer Firma im gleichen Ort?).

"firma_id" ist schon OK, ich persönlich verwende lieber "ID_Firma" (immer "ID_" führend). Wenn Du andere fragst,  hängen einige auch immer "_fk" für Foreign Key an den Namen, was ich wiederum für immer überflüssig halte.

Umgekehrt sollte der PK (Primary Key) aber ebenfalls so heißen. Ganz sicher nicht "Schlüssel" (auch nicht "ID").

Aber die Datenbank scheint dahingehend eh chaotisch zu sein, was Du nicht auf die Schnelle bereinigen kannst.
"Primärschlüssel Lieferadresse" bzw. "..Rechnungsadresse" als FK-Name in einer Bestelltabelle.. total daneben.

Namen mit Leer- und Sonderzeichen, etwa "Bestell-Nr" (wieso heißt eine Tabelle wie ein Feld? Sollte wohl eher "Bestellungen" oder noch besser "tblBestellungen" heißen), "P/N", "Serien - Nummer" uvm. - Namen sollten grundsätzlich keine Leer- und Soderzeichen beinhalten, nur Buchstaben, Zahlen, Unterstrich.
Gleiches gilt für "Rechnung-Nr" und andere solcher Namen als Tabellennamen.

ID-Felder (PKs und i.d.R. auch FKs) sollten immer an den Anfang der Tabelle. Den Grund siehst Du an den vielen Scrollbalken in Deiner Abfrage, weil das verbundene Feld jeweils weiter unten als die sichtbaren Felder steht.

"Umsatz 1991", "Umsatz 1992" usw.: Aufzählungsfelder, gehören nicht in Spalten, sondern in eine eigene Tabelle. Mit "firma_id", "Jahr", "Umsatz" und ggf. noch weitere.

"Preis 2024", "EK 2024"...

"Kunden Nr 2" und "Kundennr2"...
Besonders schön finde ich "Brange"... ;) Sollte wohl eher "Branche" heißen...

Diverse der Tabellen haben nicht einmal einen PK, den sollte man immer erstellen.

Das waren nur mal eine Reihe der Dinge, längst nicht alles.

ZitatGibt es eine Möglichkeit alle Einträge von "Schlüssel" in der Tabelle "Firma" auf einmal nach "firma_id" in "Zahlungsziel-Frachtkosten zu kopieren?
Ja, natürlich.
Solange "Firmasuch" ein eindeutiges Ergebnis erzeugt, also nicht mehr als eine Firma für jeden Eintrag der Zahlungsziel-Frachtkosten-Tabelle, kannst Du das mit einer UPDATE-Anweisung erledigen.

Am einfachsten ist, eine Abfrage zwischen den beiden zu erstellen mit ID, Firmasuch, Schlüssel, Kundennr, Firma als Ausgabefelder (zur Kontrolle) und erst mal anzuschauen, was dabei herauskommt.

Ist die Zuweisung in Ordnung, kannst Du im Designer die Abfrage auf eine UPDATE-Abfrage umstellen und dann den Wert von "Schlüssel" in "firma_id" schreiben.
Da das Feld neu ist, macht es erst einmal nichts, wenn es nicht korrekt funktioniert, kannst Du dann ja jederzeit ändern ohne Auswirkungen.

Wenn das Feld gefüllt ist, kannst Du die gleiche SELECT-Abfrage nochmal machen, nur verbindest Du dann nicht mehr Firmasuch, sondern firma_id mit Schlüssel und schaust Dir an, ob das Ergebnis stimmt. Dabei sollte die Anzahl Datensätze passen (Schnelltest) und zur näheren Prüfung der Inhalt.
Wenn alles OK ist, kannst Du die Referenz zwischen Firmasuch entfernen (im Beziehungseditor, nicht wie hier gezeigt in einer Abfrage). Wenn der Beziehungseditor keine Beziehungen anzeigt, ist es noch chaotischer. Einige denken, man könne gute Datenbanken auch einfach ohne Beziehungen bauen, was aber eine Menge Potential der Datenbanken verschenkt. Insbesondere die Einstellung zur referentiellen Integrität ist wichtig für stets saubere Daten.

Übrigens muß man auch nicht "Firmasuch" als Feld in der Tabelle führen. Das erstellt man bei Bedarf einfach aus Firma und Ort in einer Abfrage (z.B. für eine Kombobox für ein Suchfeld). Kann man dann auch generell überall entfernen, sobald vernünftige Beziehungen über ID-Felder aufgebaut wurden.

Gruß

Christian


MzKlMu

Hallo,
ich habe Dir bereits am 23. Oktober 2025 schon einiges zum Datenmodell geschrieben.

- Es fehlt referentielle Integrität
- Für die Verknüpfungen/Beziehungen werden zum Teil nicht die Primärschlüsselfelder verwendet.
- Die Verknüpfung Schlüssel zu Schlüssel ist überflüssig, da die Bestell-Nr. eindeutig ist.
- Eines der Felder "Schlüssel" ist dann zu zu löschen. Wahrscheinlich in der Tabelle "Einzelangaben_Auftrag".
- Die Felder Gesamtpreis und Summen sind in Tabellen zu löschen, solcher Felder werden im Regelfall nur berechnet.
- Felder für DM sind überflüssig, die DM lassen sich aus Euro berechnen.
- Für die Umsätze nach Jahren ist eine extra Tabelle erforderlich-
- Für die Ansprechpartner ist eine extra Tabelle erforderlich.
- Die Preise müssen in eine eigne Tabelle. Was machst Du z.B. für die Preise 2025 ein neues Feld ?
- Die Feldnamen enthalten Leer und Sonderzeichen (-)
- Die Feldnamen sind teilweise viel zu lang.

Davon hast Du leider bis heute nichts umgesetzt.

Neu dazu:
- Für die Mahnungen ist eine extra Tabelle erforderlich
- Redundante Felder
- Für die MWST ist eine extra Tabelle erforderlich



Gruß Klaus