Ich bin dabei von einer bestehenden Datenbank zB die Kunden... zu übernehmen.
In der alten DB hat die Tabelle Kunden den Autowert IDKunden (Primärschlüssel) und die Kundenummer als LongInteger.
Da an den Kundennummern die Daten wie Angebote, Rechnungen,... hängen, müssen diese Nummern mit den gleichen Werten übernommen werden. (stehen auch in den Angeboten, Rechnungen,...)
Grundsätzlich kein Problem wenn ich in der neuen DB die Tabelle Kunden wieder mit einer ID und der Kundennummer erstelle.
Meine Frage: gibt es aus fachlicher Sicht ein Problem wenn ich in der neuen DB die Tabellen Angebote, Rechnungen mit der KundenNr und nicht mit der KundenId(=Primärkey) verknüpfe?
Das Beziehungsfenster in der Anlage.
Das Datenbankmodell habe ich aufgrund von div. Anleitungen in diesem Forum erstellt.
Die Verknüpungstabellen hinter der Kundentabelle funktionieren gut scheinen mir aber sehr aufwendig, da ich bei alle Abfragen die Tabellen hinter der Kundentabelle zB für Adressen, Kommunikation... immer abfragen muss.
Hat jemand eine Idee wie ich das besser lösen sollte?
Gruß Günther
Hallo,
prinzipiell kannst Du auch die KdNr nehmen, solange es einen eindeutigen Schlüssel hat und dann vorzugsweise als Primary Key eingestellt ist. Ich würde Dir allerdings davon abraten.
Die ID soll schlicht den Datensatz als solches identifizieren. Die ID selbst sollte dabei keinen anderen Sinn erfüllen. Eine Kundennr. dagegen könnte einem "Designprinzip" entsprechen, z.B. "A334_1255". Das wiederum kann sich ändern im Lauf der Zeit - und dann mußt Du das auch in der Datenbank nachziehen. Dann kommt vielleicht der Wunsch auf, daß die alte Kundennummer noch auf alten Dokumenten steht, jetzt in der Datenbank aber nicht mehr gefunden werden kann, weil dort nur noch die neuen stehen - usw.
Mit einer ID hast Du das Problem nicht, da die Kundennr ein eigenes Feld ist und beliebig geändert werden kann, ohne die Beziehungen zwischen den Daten anpassen zu müssen. Und das beschriebene Problem mit geänderter Kundennummer kann man über eine History-Tabelle lösen, auch hier bleibt die KundenID aber immer die gleiche.
Deine 2. Frage: Es ist völlig korrekt, Daten in dieser Weise zu unterteilen. Ja, je mehr Untertabellen, desto mehr Abfrageaufwand, wenn man wirklich ALLES zusammenbringen will. Braucht man aber meistens nicht. Beispielsweise, wenn man eine Liste von Kunden hat in einem Formular, dann brauchst Du keine Megaabfrage über alle Untertabellen, Du möchtest trotzdem deren Daten mit anzeigen. Ein Formular - eine Tabelle. Das sollte immer die oberste Regel sein. Also ist das Formular nur an die Kundentabelle gebunden, eine einfache Abfrage auf nur eine Tabelle.
Weitere Daten ergeben sich, indem man Abfragen auf weitere Tabellen an den Stellen einstellt, wo sie benötigt werden. Das ist z.B. eine Kombobox, eine Listbox oder ein Unterformular. Diese haben jeweils ihre eigenen Abfragen, die sich nur auf das beziehen, was sie benötigen.
In Deinem Beispiel etwa eine Kombobox für die Eingabe des Titels. Die Kombobox fragt tblTitel ab, das Formular tblKunden. Das Formular zeigt durch die Kombobox ja den Titel an und nicht die TitelID. Deine Tabelle speichert aber die TitelID. Und so bleiben die Abfragen einfach und verteilen sich da, wo sie benötigt werden.
Es gibt daher gar nicht so viel Gelegenheiten, wo man die Daten alle zusammenbringen will, z.B. für Exporte oder Reporte (wobei Access Reports nach dem gleichen Prinzip wie Formulare verwendet werden können, auch wenn Komboboxen in Ausdrucken keinen Sinn erfüllen würden).
Auch kann man sich Zwischenabfragen erstellen, die zum Beispiel zur Kundenliste ein paar "Nebendaten" wie den Titel oder akademischen Grad usw. aus diesen Tabellen holen und als Text mit listen, wenn man es denn braucht.
Also: Alles richtig, wie es ist. Datenbanken funktionieren so und ja, Datenbankentwickler haben dadurch durchaus ein wenig zu tun. Das gehört dazu. Für all das gibt es aber genug Generatoren und neuerdings auch KI, da muß man nicht viel selbst machen, wenn man keine Lust auf SQL hat.
Guten Rutsch!
Gruß
Christian
Vielen Dank für die ausführliche und fachliche Antwort.
Ich werde versuchen das mit der KundenId umzusetzen. Wenn ich das richtig verstanden habe müssten die Untertabellen auch aufgrund der neuen KundenId den Zusammenhang mit der alten Kundennummer erkennen.
ZitatFür all das gibt es aber genug Generatoren und neuerdings auch KI, da muß man nicht viel selbst machen, wenn man keine Lust auf SQL hat.
Hast du hier Tipps für gute Generatoren?
Ich wünsche allen im Forum ein gutes und gesundes neues Jahr.
Gruß Günther
Hallo,
ein frohes neues Jahr!
Das müßtest Du schon näher erläutern. Wenn Du den gleichen Kunden in einer alten und neuen Datenbank unter verschiedenen IDs, aber mit gleicher Kundennr. hast und beide zusammenführen willst, dann mußt Du natürlich ein wenig (einmalige) Arbeit investieren, diese zusammenzuführen.
Da würde ich bei der Kundentabelle beginnen: Diese um ein Feld am Ende erweitern (am Ende: Macht es der DB leichter, muß dann die Tabelle nicht "umbauen"). Das Feld wird später wieder entfernt. Darin speicherst Du (also in der neuen Kundentabelle) über die Kundennummer gejoint mit der alten Tabelle die alte Kunden-ID.
Das spart Dir dann Kopfschmerzen, wenn Du aus anderen Tabellen der alten Datenbank die richtige neue KundenID ermitteln willst, weil Du dann einfach über das Zusatzfeld (indiziert natürlich) auf die alte Kunden-ID JOINen kannst und die neue ID in die alten Tabellen übertragen kannst.
Dabei nicht vergessen, daß die alten Tabellen (also außer der Kundentabelle, deren ID hast Du dann ja schon) importiert werden sollten, temporär, damit Du neue Tabellen erhältst, die noch keine Restriktionen wie referentielle Integrität zu anderen Tabellen etc. enthalten. Diese können dann einfach erst mal ungetestet die neue FK-ID übernehmen. Dann kannst Du sie einfach in die passenden Tabellen der neuen Datenbank integrieren, die ja bereits eine RI eingestellt haben werden. Also z.B. eine Bestellungen-Tabelle mit einer KundenID.
Generatoren:
Naja... der Abfragedesigner von Access ist ein SQL-Generator. Auch wenn er nicht immer alles richtig macht (z.B. immer HAVING bei GROUP BY verwendet, statt WHERE, was er auch kann, aber umständlich einzurichten) und viele, viele überflüssige Klammern generiert - SQL mußt Du dazu nicht können.
Wenn man die Namen der Felder gut gewählt hat (z.B. nicht Fremdschlüssel mit zusätzlichen Pre- oder Suffixen benennt, wie es viele so gerne machen, sondern einfach genauso wie das PK-Feld), dann werden auch Abfragebeziehungen oft schon automatisch richtig gesetzt. Auch bei entsprechender Einrichtung von Beziehungen im Beziehungsfenster.
Und wenn Du Deine Tabellenstruktur an z.B. Copilot übergibst, generiert es Dir auch SQL in der passenden Form, wenn man Access SQL dazusagt. Prüfen muß man es dennoch, aber der Copilot ist mittlerweile schon richtig gut. Am einfachsten über die Bing-Suchseite, rechts im Suchfeld kann man den aktivieren. Im Gegensatz zu ChatGPT gibt es keine Begrenzung in der Anzahl Fragen.
Wenn Du SQL Server verwendest, gibt es einen Abfragedesigner auch dort.
Gruß
Christian
Hallo Christian,
nochmals vielen Dank für die ausführliche Auseinandersetzung mit meinem Thema.
ZitatDas müßtest Du schon näher erläutern. Wenn Du den gleichen Kunden in einer alten und neuen Datenbank unter verschiedenen IDs, aber mit gleicher Kundennr. hast und beide zusammenführen willst, dann mußt Du natürlich ein wenig (einmalige) Arbeit investieren, diese zusammenzuführen.
In der alten DB gibt es die Tabelle StammdatenKunden mit dem PK IDKunden =Autowert, dem Feld KundenNr als LongInteger.
In allen Untertabellen steht über eine Verknüpfung die KundenNr.
In der neuen tblKunden gibt es wieder den PK KundenId und die KundenNr mit LongInteger.
Bei der Übernahme der Daten muss ich ja die Kundennr mitnehmen. Daher wieder die Spalte KundenNr. Mit dem Autowert KundenId funktioniert ja die Übernahme der KundenNr nicht.
Alle Untertabellen in der neuen DB könnte ich aber jetzt über die KundenId verknüpfen. Zur Kontolle füge ich ein Feld KundenNr ein, um die Daten besser zu kontrollieren. Kann aber dann wie von dir angeregt in Zukunft gelöscht werden.
ZitatWenn man die Namen der Felder gut gewählt hat (z.B. nicht Fremdschlüssel mit zusätzlichen Pre- oder Suffixen benennt, wie es viele so gerne machen, sondern einfach genauso wie das PK-Feld), dann werden auch Abfragebeziehungen oft schon automatisch richtig gesetzt. Auch bei entsprechender Einrichtung von Beziehungen im Beziehungsfenster.
Ist es also nicht sinnvoll die KundenID in einer verknüpften Tabelle als KundenID_F zu bezeichnen?
Mit dem _F habe ich bisher immer erkannt dass es sich um die KundenID in einer Fremdtabelle handelt.
Copilot muss ich mir anschauen. War mir bisher unbekannt.
Gruß Günther
Hallo,
Zitat von: Christiandann werden auch Abfragebeziehungen oft schon automatisch richtig gesetzt.
Die werden auch mit dem _F in den Abfragen gesetzt. Ich bin ein Fan dieses _F, (Christian weis das :) ) Der Grund hängt einfach mit dem Forum zusammmen. Dem Anfänger ist oftmals nicht klar wie die Zusammenhänge der Schlüssel sind. Wenn das _F angehängt ist, ist sofort klar was gemeint ist. Das ist schlicht und einfach aus meiner Forumserfahrung abgeleitet. Zusätzlich finde ich es vorteilhaft wenn es in einer Datenbank keine gleichen Feldnamen gibt.
Aber, das ist auch Ansichtssache das kann jeder machen wie er will, ich will da auch keine Disskusion auslösen, ich wollte nur mal meine Beweggründe schildern.
Hallo,
ja, Klaus liebt das "_F" (auch Andere). Wenn man sich aber mal angewöhnt hat, beide Schlüsselfelder immer gleich zu benennen, wird man schnell feststellen, daß alle möglichen Tools (auch bei SQL Server und anderen Datenbanken) Felder auch ohne Beziehungen an den Namen zu erkennen, was einem SEHR viel Arbeit ersparen kann.
Darüber hinaus sollte man sich ebenfalls angewöhnen, grundsätzlich IMMER alle Feldnamen zu qualifizieren (=den Tabellennamen bzw. natürlich einen kurzen Tabellenalias voranzustellen). Es ergibt sich dadurch NIE das Problem, nicht zu wissen, aus welcher Tabelle welches Feld kommt und man hat dazu auch gleich eine Abfragedokumentation, so daß man in komplexen Abfragen nicht erst die Tabellen untersuchen muß, um die Herkunft nicht nur der ID-Felder herauszufinden.
Daher plädiere ich natürlich immer dazu, ID_Felder, die zusammengehören, zusammen zu belassen. Ebenso, ID-Felder immer mit "ID_" zu beginnen und nicht "KundenID", sondern "ID_Kunde" zu schreiben. Etliche Tools sortieren Felder nach Namen und es ist dann mühsam, die ID-Felder aus einem Haufen anderer ID-Felder herauszusortieren. Aus dem gleichen Grund gehören ID-Felder in meiner Welt auch IMMER an den Anfang der Feldliste (im Tabellendesign).
Aber wie Klaus schon sagt: Das muß letzlich jeder selbst wissen, wie schwer man es sich macht... :)
Wenn Du in der neuen Datenbank die Wahl hast, solltest Du bei der KundenID (oder ID_Kunde...) bleiben. Die Kundennr kannst Du verwenden, um die richtigen Daten in den alten Tabellen zu finden und über die ID, die Du aus der Kundentabelle dann entnehmen kannst, über die ID neu zu verknüpfen. Das ist einiges an Arbeit natürlich, aber nur einmalig.
Gruß
Christian
Vielen Dank für eure fachlichen Komentare.
Ich werde vorläufig bei meinen Bezeichnungen KundenID für die Haupttabelle und KundenID_F für die Untertabellen bleiben. Ich bin derzeit noch nicht so professionell unterwegs, dass ich die von Christian aufgezeigten Vorteile nutzen kann. Für mich ist es angenehm wenn ich weiß, dass Feldbezeichnungen mit ID und ohne _F in der Haupttabelle stehen und alle Feldbezeichnungen mit _F die verknüpften Nebentabellen betreffen.
Zudem müsste ich alle Feldnamen wieder ändern.
Gruß Günther