Anfügen von Datensätzen aus unterschiedlichen Datenbanken in Zentral-Datenbank

[Paule]

Hallo,

ich stehe derzeit vor einem kleinen Rätsel bezüglich dem Anfügen von Datensätzen aus anderen Datenbanken in ein zentralen Datenbank und den Auswirkungen des Anfügens auf den Primärschlüssel.

Eine möglichst kurze Problembeschreibung:
In einem Unternehmen gibt es eine Filiale und eine Zentrale.
Eine Aufgabe der Filiale ist es, "Field Trips" zu unternehmen und Informationen über die unterschiedlichen Dörfer zu sammeln.
Die Dörfer stellen im Zielland allerdings die kleinste organisatorische Einheit dar. Darüber gibt es noch so genannte "Wards", "Districts" und "Regions".
Da die Dorfnamen häufiger gleich sind, kommt der Dorfname nicht als Primärschlüssel infrage. Soweit habe ich in der Tabelle "VillagesT" dann einen AutoWert als Primärschlüssel zugewiesen. In dieser Tabelle ist auch das "Ward" gespeichert, in dem das Dorf liegt (ebenfalls AutoWert aus der Tabelle "WardT").
Das "Ward" wiederum wird mit einem District, in dem es liegt, gespeichert (auch hier wieder AutoWert aus der Tabelle "DistrictT"). Und der DIstrict ist ebenso als Datensatz mit der Region (ebenfalls über AutoWert aus der Tabelle "RegionT" gespeichert.

Das bisherige Vorgehen war:
Das Team fährt hinaus, sammelt die Informationen und sendet diese an die Zentrale. Diese gibt die Informationen normal in die Datenbank ein. Dies funktioniert einwandfrei.

Nun besteht die Überlegung, diese Aufgabe an die Filiale abzugeben, das spart Zeit und am Ende verwendet vor allem die Filiale diese Daten, um einen Überblick über ihren zu verantwortenden Bereich zu bekommen (welche Villages gibt es in diesem Ward etc?).

Deswegen haben wir eine Datenbank für die Filiale erstellt, die genau dieselben Tabellen und Formulare wie die der Zentrale enthält. Die entsprechenden Tabellen und Formulare wurden einfach in die neue Filial-Datenbank exportiert.

Stand jetzt haben also die Filiale und die Filial-Datenbank exakt dieselbe Datengrundlage.

Nun gibt es unterschiedliche Wege zum Anfügen der Daten und ich habe soweit wohl die blödeste genommen. Ich habe einfach händisch aus der Tabelle "VillagesT" aus der Filial-Datenbank die neuen Datensätze kopiert und in der Tabelle "VillagesT" in der Zentral-Datenbank ans Ende angefügt.

An sich möchten wir gerne den Filialen mehr Eigenverantwortung geben, sodass sich an der Lösung mit der "Teil-Datenbank" für die Filiale nichts ändern soll.

Mir kam nun aber die Frage, was passiert, wenn wir eine neue Filiale eröffnen.
In der Datenbank der Filiale 1 würde ich dann wieder Datensätze aus "VillagesT" kopieren und in "VillagesT" in der Zentral-Datenbank kopieren. Dann würde ich beispielsweise die VillageID's (Primärschlüssel) 67,68,69 bekommen, wenn ich drei neue Villages hinzufüge.
Wenn aber auch drei Datensätze in "VillagesT" in der Datenbank der Filiale 2 hinzugekommen sind und ich diese in "VillagesT" der Zentraldatenbank anfügen möchte, würden das dann auch Villages 67,68,69 als Primärschlüssel sein.

Dieselben Probleme gibt es dann analog bei "WardT", "DistrictT" und "RegionT".

Ich habe jetzt schon ein bisschen im Netz gegoogelt und bin dabei auf unterschiedliche Möglichkeiten gestoßen, die in die richtige Richtung gehen. Mir scheint die Idee mit Anfügeabfragen am meisten Sinn zu machen, aber mir fehlt noch ein wenig das Verständnis für die Auswirkungen auf den Primärschlüssel und wie ich es schaffe, dass in allen Datenbanken die gleichen Primärschlüssel vergeben werden bzw. es da einfach zu keinen Überschneidungen kommt und das das gleiche Dorf in der Filial-Datenbank nicht den Primärschlüssel 68 hat, aber in der Zentraldatenbank 73 beispielsweise.

Für mich stellt sich erstmal grundlegend die Frage:
Ist eine Lösung prinzipiell erstmal mit begrenzten Access-Kenntnissen möglich, oder wird das zu kompliziert für den Laien?

[Beaker s.a.]

Hallo Paul,
Wenn du mehr als eine Filiale hast, brauchst Du eh eine Tabelle dafür.
Deren ID/PK kommt dann als FK in die VillageT. Aus dem vorhandenen
Autowert und diesem Fremdschlüssel machst Du dann den PK als Mehr-
felder-Schlüssel.
Würde mir jetzt so auf die Schnelle einfallen.
gruss ekkehard

[Paule]

Hi Ekkehard,

danke für die schnelle Antwort.

Heißt: Du würdest jeweils unterschiedliche individuelle Tabellen in den Filial-Datenbanken haben, die jeweils nur ihre Regionen/Districts/Wards/Villages abspeichern?

Ich füge dann alle neuen Datensätze von allen Village-Tabellen in meine "VillageT" aus der Zentraldatenbank an. Dabei bekommen sie einen neuen PK, aber sie übernehmen den PK, der ihnen bei der Eingabe in die Filial-Datenbank gegeben wurde als FK.

Das führt dann dazu, dass die FK's bei manchen Dörfern teilweise gleich sind, aber das macht ja nichts.

Ich frage mich viel mehr, was dann mit dem "Ward" passiert. Dieser wird ja in dem Village-Datensatz mit gespeichert.

Village 1 hätte als WardID dann 14 (aus Filiale 1)
Village 2 hätte als WardID dann eventuell auch 14 (aus Filiale 2).

Das heißt, sie hätten als Ward dann den gleichen, was ja nicht stimmt, weil die Dörfer in zwei unterschiedlichen Regionen/Filialen liegen.

Heißt, ich müsste obiges Prinzip auch bei den höheren Ebenen anwenden.
1. Anfügen der Regionen
2. Anfügen der Districte
3. Anfügen der Wards
4. Anfügen der Villages.

Das heißt, auch bei den Wards hätte ich dann einen PK bei Anfügen in meine "WardT" Tabelle in der Zentral-Datenbank, als FK nehme ich den PK aus der Filial-Datenbank.

Wenn ich nun die Village-Datensätze hinzufüge, steht doch aber immer noch die WardID im Datensatz, der von der Filial-Datenbank zugeordnet wurde.

Wie kann ich es hinbekommen, dass stattdessen mein neuer PK, den ich dem Ward bei Anfügen in meine Tabelle, gegeben habe, im Village-Datensatz übernommen wird statt dem alten PK durch die Filial-Datenbank.

Ich hoffe du verstehst meine Bedenken. Wahrscheinlich habe ich es lediglich noch nicht so ganz kapiert und stehe noch auf dem Schlauch...?!

Wäre dir sehr dankbar für ein paar weitere Worte!

[Beaker s.a.]

Hallo Paul,
Wenn ich jetzt so darüber nachdenke, denke ich, dass dein Tabellenaufbau
nicht korrekt ist. Sollte eher wie auf dem angehängten Bild aussehen.
Bin aber (noch) nicht sicher, ob das so schon richtig ist, und zur Lösung
deines Problems beuträgt. Bin etwas unter Druck heute. Schau's mir über's
WE noch mal an. Ausser einer der Cracks ist schneller und/oder weiß es
besser.
Auf jeden Fall müsstest Du so aber auch die Zentrale als eine "Filiale" anlegen.
gruss ekkehard

[Paule]

Hi Ekkehard
danke für deinen Vorschlag.
Ok, ich versuche mich am Wochenende daran. Ich muss noch die FK hinzufügen.

Ich habe lediglich nicht die Filiale, da die Regionen eigentlich gleich Filialen sind.

Heißt:
Region 1 ist auch gleich der Name der Filiale 1.
Region 2 ist auch gleich der Name der Filiale 2.

Wir bauen Filialen nach Regionen auf.

Das Headquarter selbst soll eigentlich NIE eigenständig Dörfer hinzufügen. Es soll lediglich die Datensätze der anderen Filialen zusammenführen.

Ja, kein Stress. Es eilt nicht zu sehr und würde mich jederzeit über ein paar mehr Gedanken freuen.

[Beaker s.a.]

Hallo Paul,

Ich habe lediglich nicht die Filiale, da die Regionen eigentlich gleich Filialen sind.

O.K., dann kann die Tabelle "Filialen" und der FK in "Regions" entfallen.
D.h. aber auch, das die Filialen keine Regions anlegen können/dürfen,
- oder?

soll eigentlich NIE

"eigentlich" und "NIE" ergeben für mich eine nicht leere Schnittmenge
(kann man das so ausdrücken?).
Da musst du dich entscheiden. Bei "eigentlich" musst du auch die Zentrale
als "Region/Filiale" einrichten.

Ansonsten, wie gesagt, mach ich mir über's WE noch ein paar Gedanken.

gruss ekkehard

[Paule]

Hi Ekkehard,

siehe auch PN.

Ich habe lediglich nicht die Filiale, da die Regionen eigentlich gleich Filialen sind.

O.K., dann kann die Tabelle "Filialen" und der FK in "Regions" entfallen.
D.h. aber auch, das die Filialen keine Regions anlegen können/dürfen,
- oder?

Ja, für den Testfall habe ich es aber jetzt so wie du gemacht. 2x Filial-Datenbanken, 1x Zentral-Datenbank. Und jeweils eben so wie du es vorgeschlagen hast. Sagen wir zu Testzwecken, dass Filialen ungleich Regionen sind und eine Filiale mehrere Regionen vereinen kann.

soll eigentlich NIE

"eigentlich" und "NIE" ergeben für mich eine nicht leere Schnittmenge
(kann man das so ausdrücken?).
Da musst du dich entscheiden. Bei "eigentlich" musst du auch die Zentrale
als "Region/Filiale" einrichten.

Dann nie. Das soll Aufgabe der Branch sein.

[Paule]

Hallo,

anbei mal meine Probe-Datenbanken.
Ich habe 2 Filialen angelegt und eine Zentraldatenbank. Mit entsprechendem Tabellenaufbau.
Die beiden Filial-Datenbanken haben auch Testdaten.

Ich habe in den Filial-Datenbanken schon Append-Queries angelegt, die die Daten in die entsprechenden Tabellen des Zentraldatenbank kopieren (jetzt dürfte die Verknüpfung nicht mehr passen...).

Dies hat anfangs auch super geklappt.

Dann wollte ich noch etwas ausprobieren und habe die Datensätze aus der Zentral-Datenbank gelöscht. Anschließend wollte ich die Datensätze aus den Filialen nochmals in die Zentraldatenbank einpflegen mit den Append-Queries. Nun habe ich aber Schlüssel-Verletzungen und ich weiß nicht so recht, warum.

Außerdem stellt sich mir die Frage, wie das Ganze beim Anlegen von Kunden in den Zentral-Datenbank funktionieren kann.
Da möchte ich ja im Formular "SA_Customer" die Filiale, Region, District, Ward und Village hinzufügen.
Die Listenfelder und deren Aktualisierung klappen da aber leider noch nicht wirklich und ich stelle mir das Ganze schwierig vor, weil die Regionen, Districts, Wards und Villages die PK's aus den Filial-Datenbanken, aus denen ich die Daten in die Zentral-Datenbank kopiere, ja übernehmen. Aber die sind ja teilweise gleich mit den PK's aus der anderen Filial-Datenbank.

Ich würde mich sehr über ein paar Anregungen freuen wie ich dieses Dilemma lösen kann und beim Anlegen des Kunden durch die entsprechenden Listenfelder durchklicken kann unddie entsprechenden Villages, die zu dem ausgewählten Ward gehören etc. richtig zugeordnet werden.

[DF6GL]

Hallo,

Lösungsweg:

http://www.ms-office-forum.net/forum/showthread.php?p=1633105#post1633105

und etwa hier:

http://dbwiki.net/images/8/81/AccSampleDivideTable.zip

[Beaker s.a.]

Hallo Paul,
Sorry, komme nicht vorwärts (unerwarteter Besuch).
Folgendes habe ich bis jetzt machen können.
1. Aufgrund deiner Testdaten ergibt es sich, dass es zu einem Branch
mehrere Regions gibt. Das war aus deiner Beschreibung nicht ersichtlich.
Deshalb habe ich da jetzt eine Zwischentabelle eingefügt. Diese brauchst
du in den Branches-DBs nicht. Ebenso die Tabelle "MI_BranchesT". Dafür
wird in "MI_Regions" das Feld "BranchID_FK" mit einem Standardwert
(ID des Branch) belegt.
2. In MI_RegionsT habe ich einen eindeutigen Mehrfelderschlüssel über
"RegionID_Branch" und "BranchID_FK" gelegt. Damit funzt der Import
der Regions-Tabelle(n) aus den Branches schon mal ohne Probleme.
3. Habe ich die relevanten Tabelle aus den Branch_DBs in die Zentrale-DB
importiert (...B1 und ...B2), und diese als .mdb hier angehängt.
Da können die anderen Regulars auch mal drüber schauen.

Nun habe ich aber Schlüssel-Verletzungen und ich weiß nicht so recht, warum.

Wie gesagt, mit "Regions" klappt es (s.o.). Bei den untergeordneten
Tabelle fehlt der, beim Import neu angelegte PK in MI_RegionsT.
D.h., das deren Import nicht mit einer einfachen Anfügeabfrage, wie
bei Regions funktioniert. Jedenfalls nicht ohne einen Bezug auf diesen
neuen Schlüssel. Wird wahrscheinlich über einen Formularbezug zu
lösen sein.
Ich habe mich auch schon gefragt, wie Du den Import überhaupt
vor hast. Lässt du dir Kopien der DBs schicken?
Ich würde da eher eine Schnittstelle per .csv-Dateien bevorzugen.

Außerdem stellt sich mir die Frage, wie das Ganze beim Anlegen von Kunden in den Zentral-Datenbank funktionieren kann.

Das lösen wir, wenn der Import steht.

guten Abend
ekkehard

P.S. Anmerkung zur angehängten .mdb:
Die Tabellen mit B1 bzw. B2 am Namensende sind normal externe Tabellen.
Im Beziehungsfenster ist oben das Modell der Zentrale abgebildet. Der
untere Teil wäre in den Branches anzuwenden.

[Paule]

Hallo Ekkehard,

Sorry, komme nicht vorwärts (unerwarteter Besuch).
Folgendes habe ich bis jetzt machen können.

Kein Grund sich zu entschuldigen. Eher ganz großen Dank dass du dir trotz dessen so viel Zeit für das Problem nimmst. 

1. Aufgrund deiner Testdaten ergibt es sich, dass es zu einem Branch
mehrere Regions gibt. Das war aus deiner Beschreibung nicht ersichtlich.
Deshalb habe ich da jetzt eine Zwischentabelle eingefügt. Diese brauchst
du in den Branches-DBs nicht. Ebenso die Tabelle "MI_BranchesT". Dafür
wird in "MI_Regions" das Feld "BranchID_FK" mit einem Standardwert
(ID des Branch) belegt.

Ja, ich hatte jetzt erstmal exakt den ersten Aufbau von dir übernommen. Das müsste ich auch nochmal erfragen, ob es sein kann, dass einer Branch mehrere Regionen zugeordnet werden. Aber ich denke eher nicht. Wir können es aber gerne jetzt so mal durchspielen, die Systematik bleibt ja gleich.

2. In MI_RegionsT habe ich einen eindeutigen Mehrfelderschlüssel über
"RegionID_Branch" und "BranchID_FK" gelegt. Damit funzt der Import
der Regions-Tabelle(n) aus den Branches schon mal ohne Probleme.

Ah ja. Das heißt du transferierst die Daten aus den Tabellen der Branches mittels Anfügeabfrage (?) in die Zentral-Datenbank (B1, B2 Tabellen?). Durch diesen Mehrfelderschlüssel ist dann quasi klar, welche Region zu welcher Branch gehört, auch wenn sie den selben FK (durch Import aus den Branch-Datenbanken) haben, richtig?

Ich habe mich auch schon gefragt, wie Du den Import überhaupt
vor hast. Lässt du dir Kopien der DBs schicken?
Ich würde da eher eine Schnittstelle per .csv-Dateien bevorzugen.

Ja, also die Branch soll jeden Tag die Datenbank aktuell halten. Einmal am Tag gehe ich dann in die Datenbank der Branch (wird an zentraler Stelle Dropbox/GoogleDrive gespeichert), weil ich dort die eingetragenen Ausgaben/Einnahmen in das Book-Keeping eintragen muss. Bei dieser Gelegenheit wäre es auch ein einfaches, die entsprechenden Anfüge-Abfragen auszuführen. So dachte ich mir das. Aber liegt wohl auch eher an meinem begrenzten Wissen. Wenn CSV sinnvoller ist, dann ist das natürlich besser. Es soll eben so einfach wie möglich bleiben und da erschien mir eine einfache Abfügeabfrage relativ einfach.
Also die Branch füllt nur entsprechenden Formulare aus und den Rest macht dann die Zentrale (Import in Zentraldatenbank).

Die ganzen gespeicherten Daten werden in der Zentraldatenbank eh nicht zu sehr gebraucht. Wir bräuchten sie dann eben nur um dem Kunden ein Dorf zuweisen zu können und später zu sehen, welche Aktivitäten unternommen wurden.

Wird wahrscheinlich über einen Formularbezug zu
lösen sein.

Ähm ja. Würde mich freuen, wenn du mir das erklären könntest. Denn ich würde es auch ganz gerne verstehen, damit ich es später selbst anwenden kann

Auf jeden Fall noch mal ein riesiges Dankeschön!

[Beaker s.a.]

Hallo Paul,

Ja, ich hatte jetzt erstmal exakt den ersten Aufbau von dir übernommen. Das müsste ich auch nochmal erfragen, ob es sein kann, dass einer Branch mehrere Regionen zugeordnet werden. Aber ich denke eher nicht. Wir können es aber gerne jetzt so mal durchspielen, die Systematik bleibt ja gleich.

Ja, sorry, das mit der Zwischentabelle ist natürlich Quatsch. Weiss auch
nicht, wie ich darauf gekommen bin. Ich denke nicht, dass es Regions
mit mehreren Branches gibt.
Der Aufbau müsste demnach so sein:
Branches -> Regions -> Districts -> usw.

Ah ja. Das heißt du transferierst die Daten aus den Tabellen der Branches mittels Anfügeabfrage (?) in die Zentral-Datenbank (B1, B2 Tabellen?). Durch diesen Mehrfelderschlüssel ist dann quasi klar, welche Region zu welcher Branch gehört, auch wenn sie den selben FK (durch Import aus den Branch-Datenbanken) haben, richtig?

Ja, richtig erkannt. Und in weiteren untergeordneten Tabellen (Districts,
Wards und Villages) muss auch noch so ein Schlüssel rein, - jeweils über
das Feld ...ID_Branch und den FK der übergeordneten Tabelle.
Beispiel: in Tabelle Districts über die Felder DistrictID_Branch und DistrictID_FK.
Anbei die DB mit den Abfragen zum Import (puh, mann, hab ich ganz
schön dran geknobelt). Diese musst du noch in soweit anpassen, das es
mit den externen Tabellen klappt (habe ich nicht getestet).

wird an zentraler Stelle Dropbox/GoogleDrive gespeichert

Funktioniert das wie ein normales Laufwerk? Kenne mich damit nicht aus.
Wenn dem so ist, brauchst du doch gar keine getrennten DBs (Backends).
Oder lassen sich daraus die Tabellen nicht verknüpfen?

Dein Kunden-Formular habe ich auch mal geändert. Aus den Listfeldern
habe ich (abhängige) Kombis gemacht. Diese musst du bezüglich der
Anzeige (Namen) noch anpassen (Spaltenbreiten). Normal zeigt man die
ID (1. Spalte) nicht an (Breite = 0cm).
Und wenn du dir die Datensatzherkunft der Kombis anschaust, erkennst
du auch, was ein Formularbezug ist.

gruss ekkehard

[Paule]

Hi Ekkehard,

vielen Dank!

Ja, richtig erkannt. Und in weiteren untergeordneten Tabellen (Districts,
Wards und Villages) muss auch noch so ein Schlüssel rein, - jeweils über
das Feld ...ID_Branch und den FK der übergeordneten Tabelle.
Beispiel: in Tabelle Districts über die Felder DistrictID_Branch und DistrictID_FK.

Ich habe es mal so gemacht, wie ich es verstanden habe. Siehe Screenshot. Passen die Beziehungen so?

Ja, sorry, das mit der Zwischentabelle ist natürlich Quatsch. Weiss auch
nicht, wie ich darauf gekommen bin. Ich denke nicht, dass es Regions
mit mehreren Branches gibt.
Der Aufbau müsste demnach so sein:
Branches -> Regions -> Districts -> usw.

Ok, Rolle rückwärts. Es ist nach Rückfrage nun doch möglich, dass eine Branch mehrere Regionen verwaltet. Von daher passt es also so. Sorry für die Verwirrung.

Funktioniert das wie ein normales Laufwerk? Kenne mich damit nicht aus.
Wenn dem so ist, brauchst du doch gar keine getrennten DBs (Backends).
Oder lassen sich daraus die Tabellen nicht verknüpfen?

Ja, an sich schon. Ich habe einen Dropbox-Ordner für jede einzelne Branch. Die Branch legt dann ihre Reporting-Dateien in dem Dropbox-Ordner ab. Dort ist auch die Datenbank der Branch gespeichert, die sie laufend aktualisieren.

Die Zentraldatenbank liegt allerdings nicht in der Dropbox (und folglich auch nicht im selben Ordner), sondern an anderer Stelle auf dem Laufwerk.
Würde eine Verknüpfung dennoch funktionieren?

Dein Kunden-Formular habe ich auch mal geändert. Aus den Listfeldern
habe ich (abhängige) Kombis gemacht. Diese musst du bezüglich der
Anzeige (Namen) noch anpassen (Spaltenbreiten). Normal zeigt man die
ID (1. Spalte) nicht an (Breite = 0cm).
Und wenn du dir die Datensatzherkunft der Kombis anschaust, erkennst
du auch, was ein Formularbezug ist.

Anbei die DB mit den Abfragen zum Import (puh, mann, hab ich ganz
schön dran geknobelt). Diese musst du noch in soweit anpassen, das es
mit den externen Tabellen klappt (habe ich nicht getestet).

Schau ich mir gleich an. Danke auf jeden Fall!

[Beaker s.a.]

Hallo Paul,

Es ist nach Rückfrage nun doch möglich, dass eine Branch mehrere Regionen verwaltet.

So ist es ja jetzt; - 1 Branch zu n Regions.
Die Zwischentabelle bräuchte man nur, wenn 1 Region durch n Branches
bearbeitet werden würden.

Siehe Screenshot

Finde ich nicht.

Die Zentraldatenbank liegt allerdings nicht in der Dropbox (und folglich auch nicht im selben Ordner), sondern an anderer Stelle auf dem Laufwerk.
Würde eine Verknüpfung dennoch funktionieren?

Scheinbar nicht. Ich habe hier:
http://www.hitechcoach.com/index.php?option=com_content&view=article&id=33:remote-access-for-an-access-application&catid=52:remote-access
dies gefunden:

If you place the back end on a web server, unfortunately you can not link to the tables from an Access front end over the internet.

Alternativen (Terminal-Server, (My)SQL-Server, u.ä.) werden dort auch aufgezeigt.
Wobei ich sagen muss, das deine Anwedung, wenn da richtig viele Branches
dazu kommen, förmlich nach einem SQL-Server schreit. Leider kann ich dir dabei
aber nicht behilflich sein.

gruss ekkehard

[Paule]

Hi Ekkehard,

ja sorry, Anhang vergessen. 

Jetzt aber...

Ja, im Moment bleibt es erstmal bei 2-3 Branches. Sofern dann ein größeres Investment folgt, wird das Ganze auch professioneller ablaufen und neu aufgesetzt...