Tabellen zusammenführen

[philipp-schoene]

Ich möchte aus einer Importdatenbank drei Tabellen in einer Tabelle importieren. Ich habe schon eine Spaltre mit VBA/SQL hinzugefügt, damit sich die Daten in der großen Tabelle auf jeden Fall unterscheiden.

Ich habe folgende Vorgabe. Die Daten der Importdatei sollen abgeglichen werden. Neue Datensätze sollen hinzugefügt werden. Die Fälle "Änderung" und "Löschen" gibt es nicht.

Sollte ich denn jedesmal die komplette Tabelle löschen und dann neu importieren, oder leiber den meiner Meinung Sicheren Weg gehen und jeden Datensatz prüfen und eventuell einfügen?

Die Importdaten enthalten immer alle Datensätze, also nicht nur die Veränderungen. Aber sicher ist sicher.

Den Import mache ich mit einem Formular mit Button. D. h. Ich würde es gern in VBA machen.

Vielen Dank schonmal für eure Hilfe.

[Amstelchen]

mach dir für die drei tabellen jeweils eine anfügeabfrage. diese kannst du dann direkt per VBA triggeren. wenn du sie nicht als solche abfragen vorhalten willst oder sollst, nimm dir den SQL davon heraus und führ ihn per (bevorzugt) Execute oder RunSQL aus.

du kannst mit einfachen bzw. zusammengesetzten primärschlüsseln vermeiden, dass datensätze doppelt angefügt werden.

wen der import irrtümlich ein zweites mal läuft, werden doppelte datensätze (mit oder ohne meldung) zurückgewiesen.

s'Amstel

[philipp-schoene]

Anfügeabfragen fügen immer an, auch wenn der Datensatz schon existiert, oder?

Vielleicht habe ich mich auch nicht richtig ausgedrückt: Also DB 1 ist die Importdatei. DB 2 ist mein Projekt. Ich habe von DB 1 Tabelle a,b und c in DB importiert. Die Tabellen ab, und c sollen zu einer Tabelle zusammenfasst werden. (Ich habe schon mittel VBA/Sql eine neune Spalte mit einem Wert pro Tabelle eingefügt.

Was ich vielleicht etwas unglücklich gesagt habe: Die Quelle enthält alle Datensätze. Egal ob die sich seid dem letzten Mal geändert haben oder nicht. Ich brache nur die neu hinzugefügten Datensätze übernehmen.

Ich habe Anfügeanfragen erstellt. Aber die fügen immer an, also wenn die Qulle 90 Sätze enthält, dann 90,180, 270 usw. Da war nicht so gemeint. Sorry

[Amstelchen]

Anfügeabfragen fügen immer an, auch wenn der Datensatz schon existiert, oder?

wenn sie nicht durch einen eindeutigen schlüssel daran gehindert werden.

es wäre hilfreich zu wissen, wie die tabelle aussehen, und welche felder für schlüssel in frage kommen, bzw. welche besitzen.

ist die quelle denn die exportierte buchhaltungs-DB aus deinem anderen thread?

s'Amstel

[philipp-schoene]

Genau es handelt sich um das von dir genannte Thema: http://forum.fachinformatiker.de/basic/118341-daten-access-anderer-db-importieren.html

Die Tabellen haben keinen Index.Sie bestehen nur aus Kontonummer, Bezeichnung und Mandant. Ich habe mir gedacht, wenn ich drei Tabellen habe, dann brinjgt mir ein Index auch nichts, da der bei jeder Tabelle doch bei 1 beginnt.

[flashpixx]

Um an den ursprünglichen Thread anzuschließen. In meinem letzten Posting hatte ich Dir das mit den Schlüssel usw erklärt.

Phil

[philipp-schoene]

Um an den ursprünglichen Thread anzuschließen. In meinem letzten Posting hatte ich Dir das mit den Schlüssel usw erklärt.

Phil

ich kann deinen beschriebenen Fall nicht auf mein Projekt übertragen. Aber vielleicht sehe ich was nicht, was für dich selbstverständlich ist. Meiner Ansicht nach sind schon von den Konten die Spalten Mandant und Kontonummer zusammen einzigartig.

[flashpixx]

Es ist genau das gleiche das @Amstelchen beschrieben hat. Du musst dafür Sorge, dass Deine Tabelle einen eindeutigen Schlüssel besitzt, dann kannst Du mit einem "INSERT IGNORE INTO" einfach neue Datensätze in die Tabelle einfügen, ohne dass Fehlermeldungen entstehen, oder alte Sätze überschrieben werden.

Ich empfehle Dir wirklich, Dir ganz dringend Basiswissen zu Datenbanken und SQL an zu eigenen. Ich hatte Dir in dem älteren Thread das Prinzip von Schlüsseln erklärt, sogar recht ausführlich. Zusätzlich musst Du entsprechend SQL beherrschen, um die Probleme umzusetzen. Via Drag&Drop ist hier schon Schluss. Ich kann Dir wirklich die beiden Bücher zum Datenbankentwurf empfehlen:

Amazon.de: Datenbankentwurf: Eine beispielorientierte Einführung für Studenten und Praktiker: Helmut Jarosch: Bücher

Für SQL ist dieses Buch als Einstieg empfehlenswert: Amazon.de: SQL in 21 Tagen . Die Datenbank-Abfragesprache SQL vollständig erklärt: Stephans, Plew, Morgan: Bücher

Bei mir entsteht der Eindruck, dass Du noch nicht verstanden hast, was Primär- und Fremdschlüssel bewirken. Ebenso Du keine Grundlagen von SQL und der DML besitzt. Aufgrund deines OP "Ich möchte aus einer Importdatenbank drei Tabellen in einer Tabelle importieren." ist dies letztendlich immer noch die Fragestellung des ursprünglichen Threads.

Es beläuft sich letztendlich auf ein "INSERT IGNORE INTO ... SELECT ... JOIN ...WHERE" das Du ausführen musst.

Phil

[philipp-schoene]

Es beläuft sich letztendlich auf ein "INSERT IGNORE INTO ... SELECT ... JOIN ...WHERE" das Du ausführen musst.

Phil

Es hat schon Gründe, wenn man mehrfach fragt. Vielleicht waren die Antworten nicht gut. Ihr habt zum Beispiel nicht

Klar brauche ich einen Primärschlüssel. Ich dachte aber, dass ich den erst in der zusammengefassten Tabelle erzeuge. Da kann ich den Index ja einfach durchzählen.

Ist diese Vorgehensweise nicht OK?

[flashpixx]

Klar brauche ich einen Primärschlüssel. Ich dachte aber, dass ich den erst in der zusammengefassten Tabelle erzeuge. Da kann ich den Index ja einfach durchzählen.

Was passiert in diesem Fall, wenn ich den Import 2 mal laufen lassen mit den identischen Daten ohne vorher die Daten aus der Zieltabelle zu löschen

Phil

[philipp-schoene]

Was passiert in diesem Fall, wenn ich den Import 2 mal laufen lassen mit den identischen Daten ohne vorher die Daten aus der Zieltabelle zu löschen

Phil

Genau, deswegen wäre es schön, wenn nur die neuen Datensätze übernommen werden. Ich denke, da bleibt nur das Vergleichen des Mandanten und der Kontonummer. Kann das SQL oder muss man da eine Schleibe schreiben, in der man alles vergleicht?

[flashpixx]

Genau, deswegen wäre es schön, wenn nur die neuen Datensätze übernommen werden. Ich denke, da bleibt nur das Vergleichen des Mandanten und der Kontonummer. Kann das SQL oder muss man da eine Schleibe schreiben, in der man alles vergleicht?

Liest Du das überhaupt was ich geschrieben habe !?

Ich zitiere mich einmal selbst:

Es ist genau das gleiche das @Amstelchen beschrieben hat. Du musst dafür Sorge, dass Deine Tabelle einen eindeutigen Schlüssel besitzt, dann kannst Du mit einem "INSERT IGNORE INTO" einfach neue Datensätze in die Tabelle einfügen, ohne dass Fehlermeldungen entstehen, oder alte Sätze überschrieben werden.

Phil

[philipp-schoene]

Liest Du das überhaupt was ich geschrieben habe !?

Ich zitiere mich einmal selbst:

Phil

Klar lese ich das. Was ich nur nicht verstehe:

Tabelle a hätte einen Index. Der fängt bei 1 an

Tabelle b hätte einen Index. Der fängt bei 1 an

Tabelle c hätte einen Index. Der fängt bei 1 an

Nun hätte ich ja keine eindeutigen Schlüssel mehr, wenn ich die in eine Tabelle zusammenführe oder? In der zusammengefassten Tabelle kann ich schon einen Primärschlüssel anlegen. Aber in welcher Relation steht der zu den Primärschlüssel der Tabellen a, b, c?

Wätre nett, wenn ich mir das bitte erklärt.

[flashpixx]

Klar lese ich das. Was ich nur nicht verstehe:

Bitte lies noch einmal das Post #31 von mir (http://forum.fachinformatiker.de/basic/118341-daten-access-anderer-db-importieren.html).

Das ist die Antwort auf Deine Frage (der erste Teil des Post)!

Dann empfehle ich Dir diese beiden Beschreibungen des Syntax einmal zu lesen: MySQL :: MySQL 5.0 Reference Manual :: 12.2.4.3 INSERT ... ON DUPLICATE KEY UPDATE Syntax

MySQL :: MySQL 5.0 Reference Manual :: 12.2.4 INSERT Syntax

unter Access wird es in ähnlicher Form funktionieren. Zusätzlich bitte ich Dich endlich einmal Dir einschlägige Literatur über Datenbanken und SQL zu besorgen und zu lesen. Denn diese Fragen drehen sich im Kreis.

Du willst aus einer Zahl von Tabellen eine machen, somit erstelle Dir eine passende Zieltabelle, wähle den PK passend, so dass Du die Datensätz sinnvoll (!) identifizieren kannst. Ich empfehle Dir einen zusammengesetzten PK, der aus dem PKs der einzelnen Tabellen besteht. Zum Schluss fügst Du die Daten via SQL Statement entweder mit einem INSERT IGNORE oder INSERT ... ON DUPLICATE KEY UPDATE ein, wie Du es dann genau brauchst.

Phil

[philipp-schoene]

Bitte lies noch einmal das Post #31 von mir (http://forum.fachinformatiker.de/basic/118341-daten-access-anderer-db-importieren.html).

Das ist die Antwort auf Deine Frage (der erste Teil des Post)!

Habe ich gemacht. Da tauchen aber Differenzen mit meinem Rohdaten auf:

Sprich in Deinem konkreten Fall: Mandenten PK + PK der jeweiligen Buchungstabelle = PK Deiner gesamten Tabelle. Die Identifizierung immer mit Mandant. Aber Achtung: ich weiß nicht, wie der Export aussieht. Gerade bei Buchungssachen sind die PKs manchmal bisschen fies designed.

Meine Importdaten haben keinen PK. Also muss ich welche Definieren. Ich denke mal in ganz kleinen Schritten: Welche muss ich nun nehmen. Aus meiner Sicht Mandant und Kontonummer. Denn denn sind ja zusammen Einzigartig. Warum du auf die Andere Wertetabelle gehst, erschließt sich mir nicht. Ich arbeite nur mit den Konten!!! Dies als Kommentar dazu.

Dann empfehle ich Dir diese beiden Beschreibungen des Syntax einmal zu

Zusätzlich bitte ich Dich endlich einmal Dir einschlägige Literatur über Datenbanken und SQL zu besorgen und zu lesen. Denn diese Fragen drehen sich im Kreis.

icvh habe noch 54 Tage Dienst. Privat werde ich mir nicht ein teueres Buch kaufen. Denn privat werde ich mich danach nicht mehr mit beschäftigen. Und von meinem Chef kommt auch nciht viel. Ich habe ihm mal gesagt, dass ich nicht so wirklich weiterkomme...

Ich bezweifel auch, dass ich das Projekt bis dahin fertig bekomme.

So nun mal Schritt für Schritt:

Du willst aus einer Zahl von Tabellen eine machen, somit erstelle Dir eine passende Zieltabelle,

Habe ich gemacht Zieltabelle(tblKonten): Spalten ID, Mandant, Kontonummer und Bezeichnung

wähle den PK passend, so dass Du die Datensätz sinnvoll (!) identifizieren kannst. Ich empfehle Dir einen zusammengesetzten PK, der aus dem PKs der einzelnen Tabellen besteht.

Da bleiben Fragen offen: Zusammengesetzt. Also Klar einer der importtabellen. Aber da braucht man noch einen 2 Part. Welchen meinst du da? Den Rest zu besprechen, macht mehr Sinn, wenn wir das geklärt haben!

Zum Schluss fügst Du die Daten via SQL Statement entweder mit einem INSERT IGNORE oder INSERT ... ON DUPLICATE KEY UPDATE ein, wie Du es dann genau brauchst.

Phil

[flashpixx]

Habe ich gemacht. Da tauchen aber Differenzen mit meinem Rohdaten auf:

Das war mir schon bei Deinem ersten Posting klar...

Meine Importdaten haben keinen PK.

...und dieser Fall war auch logisch. Deswegen der Ratschlag ODBC Zugriff und zuerst einmal die Orginaltabellen, deren Beziehungen und Schlüssel anschauen. Das heißt ja noch lange nicht, dass man auch auf den Originaldaten arbeiten muss.

Also muss ich welche Definieren. Ich denke mal in ganz kleinen Schritten: Welche muss ich nun nehmen. Aus meiner Sicht Mandant und Kontonummer. Denn denn sind ja zusammen Einzigartig.

Ich kann Dir nicht sagen, wie Du sie definieren musst, weil ich die Datenbank nicht kenne.

Warum du auf die Andere Wertetabelle gehst, erschließt sich mir nicht. Ich arbeite nur mit den Konten!!! Dies als Kommentar dazu.

Welche Wertetabellen? Du möchtest mehrere Tabellen in eine zusammen bringen und bei mehrfachen Einfügen keine Duplikate erhalten bzw. Du möchten Daten aus einer Tabelle lesen und in eine neue schreiben ohne Duplikate.

icvh habe noch 54 Tage Dienst. Privat werde ich mir nicht ein teueres Buch kaufen. Denn privat werde ich mich danach nicht mehr mit beschäftigen. Und von meinem Chef kommt auch nciht viel. Ich habe ihm mal gesagt, dass ich nicht so wirklich weiterkomme...

Dann würde ich es auch dabei belassen. Denn Dir fehlen wichtige Grundlagen, die Du Dir aneignen musst. Wenn Du auf der einen Seite dich nicht damit weiter auseinander setzen möchtest bzw. Du auch in diesem Hinblick keine Unterstützung bekommst, dann ist jede weitere Diskussion hinfällig

Ich bezweifel auch, dass ich das Projekt bis dahin fertig bekomme.

Das ist Deine Sache.

So nun mal Schritt für Schritt:

Ich werde Dir hier nicht in kleinen Schritten sagen, was Du wie und wo zu tun hast, damit Du Dein Projekt fertig bekommst. Generelle Dinge kannst Du in einschlägiger Literatur nachlesen und wenn dann etwas unklar ist gezielt Fragen stellen. Ich habe Dir schon innerhalb des Ursprungsposting die Lösungsschritte beschrieben. Wie Du dahin kommst, das musst Du Dir schon selbst aneignen. Dir alle Schritte im Detail zu erklären ist im Sinne des Forums nicht möglich.

Phil

[philipp-schoene]

Ich füge die Tabellen nun mit einem

DoCmd.RunSQL "INSERT INTO tblKonten (Mandant, Kontonummer, Bezeichnung1) SELECT Mandant, Kontonummer, Bezeichnung1 FROM import_Konten_Domladen WHERE Kontonummer <> ALL (SELECT Kontonummer FROM tblKonten WHERE Mandant = '0')"

Das klappt ganz gut. Nun ist ein Problem gelöst. Das nächste kommt:

Ich muss Werte der Jahre sammeln. Die Originaltabellen haben 30 Spalten und je nach Größe des Mandanten zwischen 90 und 339 Datensätze Groß. Man könnte sie wie die Konten zusammenfassen und daraus eine Tabelle mit 30 Spalten und zur Zeit 573 Datensätzen machen.

Nun sollen jedes Jahre neue Daten hinzukommen. die die gleiche Struktur haben, die die Tabellen oben.

Soll ich nie Spalten mit dem Jahr bezeichnen und an die erste anhängen? Dies würde heißen, dass ich nach 10 Jahren schon 300 Spalten habe. Ist die Speicherung sinnvoll?

Gibt es bessere Methoden? Ich halte das für sehr viel Datenmenge. Ist es besser jedes Jahr eine neue Tabelle anzulegen? Letzteres finde ich persönlich besser.

[flashpixx]

Das klappt ganz gut. Nun ist ein Problem gelöst. Das nächste kommt:

fein

Ich muss Werte der Jahre sammeln. Die Originaltabellen haben 30 Spalten und je nach Größe des Mandanten zwischen 90 und 339 Datensätze Groß. Man könnte sie wie die Konten zusammenfassen und daraus eine Tabelle mit 30 Spalten und zur Zeit 573 Datensätzen machen.

spricht etwas dagegen es so zu machen?

Nun sollen jedes Jahre neue Daten hinzukommen. die die gleiche Struktur haben, die die Tabellen oben.

Soll ich nie Spalten mit dem Jahr bezeichnen und an die erste anhängen? Dies würde heißen, dass ich nach 10 Jahren schon 300 Spalten habe. Ist die Speicherung sinnvoll?

Mach ein Feld "Jahr" in die Tabelle, das Du dann passend füllst, aber normalerweise haben Buchungsdatensätze ein Buchungsdatum, mit dem Du direkt arbeiten kannst

Gibt es bessere Methoden? Ich halte das für sehr viel Datenmenge. Ist es besser jedes Jahr eine neue Tabelle anzulegen? Letzteres finde ich persönlich besser.

Nein, und 500 Datensätze sind nicht viel. Wenn Du mal in die Größenordnung 10^4, 10^6 Datensätze kommst, dann würde ich mir Gedanken machen. Datenbanken sind für riesige Datenmengen gedacht

Phil

[Amstelchen]

Ist es besser jedes Jahr eine neue Tabelle anzulegen? Letzteres finde ich persönlich besser.

bitte nein - nicht für jedes jahr eine tabelle anlegen. das ist IMO eine todsünde der normalisierung.

bei vielen datensätzen pro jahr und vielen jahren kann man ja - abhängig vom RDBMS - eine partitionierungsstrategie (pro jahr und z.b. monat) fahren - aber selbst bei access kann man ruhig daten von 1988 bis 2008 in *EINE* tabelle spielen.

s'Amstel

[flashpixx]

bitte nein - nicht für jedes jahr eine tabelle anlegen. das ist IMO eine todsünde der normalisierung.

Ich hatte dem OP mehrfach schon geraten die Grundlagen des Datenbankdesigns zu lernen, deshalb ist dieses nicht ungewöhnlich

Phil

[philipp-schoene]

Ich hatte dem OP mehrfach schon geraten die Grundlagen des Datenbankdesigns zu lernen, deshalb ist dieses nicht ungewöhnlich

Phil

Wenn du dich jeden Tag damit beschäftigst, ist es normal, dass du dich mit dem Thema besser auskennst.

Ein Forum ist dazu da, dass man auch mal Fragen stellt. Ich mache mir Gedanken so gut es eben geht. Und damit ich nichts in die falsche Richtung Entwickele frage ich eben nach.

Somit ist dein Beitrag überhaupt nicht konstruktiv!!!

Manchmal liege ich eben auch falsch. Aber daraus lernt man.

So, nun wieder zum Thema:

Ich möchte nun an eine Tabelle immer Spalten hinzufügen. In meinem Fall kann der Anwender mehrfach im Jahr Daten importieren. In dem Fall würden die Spalten in der Tabelle schon existieren. "IF NOT EXIST" geht in Access ja nicht. Kann ich auf eine andere Art prüfen, ob die Spalten da sind, und wenn nicht diese hinzufügen?

Was ist noch nicht weiß, da kann ich mich aber erst mit beschäftigen, wenn die Buchhaltung wieder da ist, Wie die Tabellen aussehen, wenn man mitten im Jahr Daten importiert. Ich schätze, dass die anderen Perioden, du noch nicht gelaufen sind, nur 0 enthalten. Auch muss ich klären, ob Rückwirkend noch Werte geändert werden können.

Mir wäre erstmal geholfen, wenn ich wüsste, wie ich die Existenz von Spalten prüfen kann.

[flashpixx]

Somit ist dein Beitrag überhaupt nicht konstruktiv!!!

Manchmal liege ich eben auch falsch. Aber daraus lernt man.

Vielleicht würdest Du damit beginnen, einmal die Fragen, die Du stellst in entsprechender Fachliteratur nach zu schlagen bzw. Grundlagen zu lernen, denn dann würdest Du solche Fragen erst gar nicht stellen.

Ich möchte nun an eine Tabelle immer Spalten hinzufügen. In meinem Fall kann der Anwender mehrfach im Jahr Daten importieren. In dem Fall würden die Spalten in der Tabelle schon existieren. "IF NOT EXIST" geht in Access ja nicht. Kann ich auf eine andere Art prüfen, ob die Spalten da sind, und wenn nicht diese hinzufügen?

Was ist noch nicht weiß, da kann ich mich aber erst mit beschäftigen, wenn die Buchhaltung wieder da ist, Wie die Tabellen aussehen, wenn man mitten im Jahr Daten importiert. Ich schätze, dass die anderen Perioden, du noch nicht gelaufen sind, nur 0 enthalten. Auch muss ich klären, ob Rückwirkend noch Werte geändert werden können.

Eine Tabellen Struktur wird genau einmal definiert und nicht einfach on-the-fly ein paar Felder dazu gebaut. Lies Dir mal wenigstens die Wiki Artikel über Normalisierung Normalisierung (Datenbank ? Wikipedia) und über das ERM Entity-Relationship-Modell ? Wikipedia durch und überlege, ob Dein Modell korrekt ist.

Die Antwort auf Deine Frage werde ich bewusst auslassen, denn solche Projekte enden fast immer damit, dass dann ein Nachfolger extrem viel Arbeitsaufwand in das Redesign stecken muss. Ich bin der Meinung, dass es kein Problem darstellt zunächst ein passendes Modell zu entwickeln.

Somit ist dein Beitrag überhaupt nicht konstruktiv!!!

Meine gesamten Postings über die 2 Threads sind konstruktiv, denn sie zeigen Dir einen Weg auf, den Du gehen kannst. Du möchtest, entgegen des fachlichen Rates, nach eigenen Strukturen diese Datenbank aufbauen, ohne Dir die Grundlagen anzueigenen. Aufgrund aller Post würde ich mich hinsetzen und entweder die entsprechenden Dinge lernen oder eben das Projekt von jemanden anderen betreuen lassen.

Phil

[philipp-schoene]

Ich werde nur auf einen Punkt reagieren:

Wie soll ich denn sonst die Daten die nach Konten, Perioden, und Jahren strukturiert abgespeichert sind halten?

[philipp-schoene]

Beim Mittagessen habe ich nochmal nach gedacht:

Ich könnte die Konten als Spalten nehmen. Allerdings muss ich dann "On-The-Fly" bei neunen Konten auch neue Spalten hinzufügen. Dies ist aber nicht so oft, wie neue Jahre hinzufügen.

Wenn ich aber die Kontonummern als Spalten nehme fallen die zusammengesetzten Schlüssel weg. Weiß nicht, wie schlimm das ist.

[philipp-schoene]

Kann man hier nicht Beiträge editieren? Habe keine solche Funktion gefunden.

Ich finde dass es nicht Sinnvoll ist, wenn man die Kontonummern in die Spalten packt. Denn die doppeln sich und sind nur zusammen mit den Mandanten eindeutig. Wie kann ich die Tabellen denn sinnvoll gestalten?