Jede Tabelle sollte einen Primärschlüssel haben, der immer eindeutig ist. Dieser ist meistens vom Format Autowert mit dem Namen ID und wird vom System vergeben. Die ID definiert den Datensatz, den man so immer eindeutig mit nur einer Zahl identifizieren kann. Zusätzlich lassen sich sprechende Indizes anlegen über die dann zum Beispiel bei 1:n Beziehungen Schlüssel (eindeutig) und Fremdschlüssel definiert werden. (Siehe Beziehungsfenster). Das verhindert Doppelerfassungen in der Primärtabelle. Datenbankpuristen bevorzugen aus Performancegründen die Verknüpfung von Tabellen über die IDs. Für kleine Datenbanken mit wenigen tausend Sätzen bevorzuge ich die Beziehung der Tabelle über die zusätzlichen Indizes, weil dann immer sofort ersichtlich ist, über welches Feld Tabellen miteinander verknüpft sind.
In diesem Fall lässt sich das mit den doppelten Schlüsseln wahrscheinlich reparieren, wenn du von Hand die mehrfachen Sätze in KDBestellungen jeweils genau der passenden alten und dann neuen/geänderten OSPNNR aufspalten und zuordnen kannst. Wenn die OSPNNR wirklich eigentlich eindeutig sein sollte, müssen die Doppelten in der Teiletabelle auf einen eindeutigen Wert geändert und parallel deren korrespondierende Sätze in KDBestellungen angepasst werden. Ein neues Feld braucht es nicht.
Vorgehensweise:
Löse eine evtl. vorhandene Beziehung der beiden Tabellen im Beziehungsfenster (auf die Verbindungslinie klicken, wenn vorhanden, und ENTF).
Ändere in der Teiletabelle die Werte der doppelten OSPNNRs auf einen jeweils eindeutigen Wert.
Ändere dann die OSPNNRs in der KDBestellungen auf den jeweils zugehörigen, ggf. neuen, Wert in der Teiletabelle. (Das geht, wie gesagt nur, wenn Du die Enden an dieser Stelle zusammen bekommst. Wenn nicht, kannst Du nur alle alten Sätze einer (neuen) PseudoOSPNNR zuordnen um sie so als "Achtung, da war was" zu kennzeichnen.)
Sind nun alle Sätze in der Teiletabelle eindeutig und die passenden Sätze aus KDBestellungen im dortigen Feld OSPNNR zugeordnet, kannst Du das Feld OSPNNR in der Teiletabelle zum Primärschlüssel machen. Gehe dazu in die Entwurfsansicht, klicke mit der rechten Maustaste auf das Feld und wähle Primärschlüssel. Sind alle Werte in den vorhandenen Sätze in der Tabelle tatsächlich in diesem Feld eindeutig, legt Access den Primärschlüssel an und lässt in Zukunft in diesem Feld keine Doppelerfassung mehr zu. Gibt es weiterhin doppelte Inhalte in diesem Feld scheitert die Anlage eines Primärschlüssels.
Nun kannst Du die 1:n Beziehung zur Tabelle KDBestellungen (wieder) herstellen. Gehe dazu ins Beziehungsfenster. Falls die Tabellen dort nicht zu sehen sind, kannst Du sie über rechte Maustaste hinzufügen. Ziehe nun einfach das Feld OSPNNR aus der Teiletabelle auf das Feld OSPNNR in KDBestellungen. Access erkennt den Primärschlüssel und legt automatisch die richtige 1:n Beziehung an.
Diese wird in Zukunft immer vorgeschlagen, wenn Du Abfragen auf die Tabellen erstellst oder Formulare/Berichte mit Hilfe eine Assistenten generierst. Wenn in KDBestellungen nun ein Satz angelegt und dort ein Wert in OSPNNR eingegeben wird, geht das nur, wenn schon ein Satz in der Teiletabelle zu dieser OSPNNR vorhanden ist.
Dieses grundlegende Wissen über Tabellen, Beziehungen, Vermeidung von Redundanzen (Normalisierung) solltest Du dir unbedingt aneignen, bzw. vertiefen, bevor Du die neue Datenbank konzipierst. Das Datenmodell entscheidet, ob eine DB später übersichtlich und ohne großen Aufwand pflegbar bleibt. Nicht zuletzt, wenn man später doch noch auf ein anderes Backend portieren möchte, ist die Struktur entscheidend, ob das einfach möglich ist.
Viele Grüße
Andreas
Bekannter Maßen sind (Long)Integer und Gleitkommaaktionen schneller ausgeführt als Stringoperationen, was sich besonders bei der Indexsuche auf die Performance auswirkt. Aber in dem Rahmen dieser Fragestellung, mit den wenigen Daten, fällt das nicht ins Gewicht, weshalb "sprechende" Indizes für den Entwickler erstmal transparenter sind. Was nicht heißen soll, dass die Tabellen keine IDs haben sollen.
