PDA

Vollständige Version anzeigen : in Access eine Sammeltabelle erstellen


Burlie
18.06.2012, 07:35
Hallo,

ich habe folgendes Problem.
Ich bekomme wöchentlich eine Excel Tab (Tabelle.gif) mit folgendem Aufbau:

nun möchte ich diese daten in eine Acc Tabelle fortlaufend einlesen.
sollte meiner Ansicht so aussehen: Spalten von Wo1 bis Wo53
Zeilen je nachdem was kommt, es sind leider nicht immer alle Zeilen gleich.
(Tabelle acc.gif).
In meiner Denke bin ich noch Excel lastig und komm nicht weiter.
Vielleicht hat ja einer einen Anstoß für mich.
Danke im voraus.

CptChaos
18.06.2012, 07:47
In meiner Denke bin ich noch Excel lastig und komm nicht weiter
Dann empfehle ich Dir dringendst die Excelbrille durch eine Accessbrille zu tauschen ;)
Schau Dir dazu am besten mal www.access-tutorial.de an

Wenn Du uns noch etwas näher erklärst um was es sich hier handelt (welches reale Thema soll hier abgebildet werden?) kann man Dir noch konkreter helfen.

Grundsätzlich: Die Tabelle sollte nicht breit (viele Spalten/Felder) sondern lang (viele Datensätze) werden

Burlie
18.06.2012, 13:15
Hallo,

ich bin des Access eigentlich schon mächtig, aber ich steh hier irgendwie auf dem Schlauch, nicht technisch, sondern theoretisch:
wenn ich die Excel in Acc eingelesen habe (per Makro) erzeuge ich eine identische Tabelle in Access.
Ich hab die db und die excel beigefügt, ich kann das schlecht erklären.
Arbeitsschritte:
1. Die Excel per Makro in Acc holen (schon erl. in Acc ist Tab vorhanden)
2. per Abfrage und eingebauter Funcion wird eine "ID" erzeugt (zur eindeut. Ident.)
3. Diese Daten sollen nun zur jeweiligen Woche (Spaltenbezeich. 1...bis n) entsprechend der jeweiligen "eigenen ID" abgelegt werden.

Vielleicht ist es jetzt verständlicher, ich kanns nicht besser beschreiben.
Danke.

Anne Berg
18.06.2012, 13:37
Hallo,

ich denke, du solltest dich bei der Gelegenheit auch gleich von den Wochenspalten trennen und die Woche als Zahl in einem separaten Datenfeld speichern. Vermutlich willst du die Daten auch auswerten können, oder?

Marsu65
18.06.2012, 14:00
Hallo zusammen,

die Empfehlung von Benny bezog sich wohl auf
sollte meiner Ansicht so aussehen: Spalten von Wo1 bis Wo53
Das macht man so in Datenbanktabellen nicht; das ist Excel-Denke. ;)

Empfohlener Tabellenaufbau:
Eigene ID | Klasse | KW | WERT
(werden die Excelfelder O und A nicht benötigt? sehe gerade, dass diese in deine ID-Erstellung einfliessen )

Entweder fügst du noch z.B. einen Autowert als Primärschlüssel ein oder
bildest aus deiner eigenen ID und der KW einen zusammengesetzten Primärschlüssel.

Die Felder AUTO und EIGENE ID (man sollte Leerzeichen vermeiden! Besser ist z.B. Eigene_ID) enthalten IMHO die selbe Information
und unterscheiden sich nur im Format. Daher würde ich ein Feld entfernen, da du sonst redundante Daten in der Tabelle hast.

Das alles macht vielleicht das Einlesen der Exeltabellen nicht einfacher, ist aber konform zur Datenbankdenkweise und erleichtert weiteres vorgehen.

Burlie
18.06.2012, 14:37
Hallo Marsu65,

das Feld eigene_ID ist praktisch der Primärschlüssel, den gibt es nur einmal.
Den brauche ich auch noch als Verknüpfung zu anderen Tabellen in der db.

Die in deinen Augen nicht benötigten Spalten, da gebe ich dir Recht, werde ich pö a pö löschen, nur momentan ist es zu meiner pers. Übersicht no hilfreich.

Dein empohlener Tab-Aufbau gefällt mir, das checke ich mal....wird zwar elendig lang das Ding, aber egal (ca 7000 Zeilen für 5 Wochen) naja...

Gibt es eigentlich, ausser der Datenbankgrösse 4GB, eine Beschränkung auf Zeilenanzahl in Acc.?

Danke.

Burlie
18.06.2012, 14:39
Hallo Anne Berg,

mach ich, klar, ist aber erst Problem #342, momentan stehe ich erst bei #19.:)
Trotzdem Danke für die Antwort.

maikek
18.06.2012, 14:58
Moin,
Gibt es eigentlich, ausser der Datenbankgrösse 4GB, eine Beschränkung auf Zeilenanzahl in Acc.?
Beschränkung Feldanzahl ("Spaltenanzahl") auf 255, die Anzahl der Datensätze ("Zeilenanzahl") ist unbeschränkt - höchstens dass es irgendwann Probleme mit dem Bereich des Datentyps des Primärschlüssels geben könnte ...
maike

CptChaos
18.06.2012, 15:05
Zu Post #6 und #7 folgende Anmerkungen:
Access ist nicht Excel! Wenn Du Dich bereits mit Access auskennst (Post #3) verstehe ich nicht, wieso an Deiner Exceldenke (Post #1) festhältst...

Datenbankdesign beginnt auf einem leeren Blatt mit Bleistift, Radiergummi und reichlich zu trinken :)
Erst wenn das Datenmodell steht, werden die Tabellen z.B. in Access angelegt.
Einfach "mal von Excel nach Access übernehmen und dann 'pö a pö' und 'mach ich dann mal'" funktioniert in den meisten Fällen nicht oder nur mit erheblichem Mehraufwand.

Formuliere und halte fest was (aus der Realität) die DB abbilden und was später mit den erfassten Daten passieren soll.
Aus diesem "Anforderungskatalog" entsteht dann das Datenmodell und aus diesem wiederum die Grundlage für Deine Datenbank/Anwendung.

Anne Berg
18.06.2012, 15:08
@Burlie,

ich meinte eigentlich dasselbe wie Marsu, nämlich das Umspeichern von Spalten in Zeilen.
Und wie hattest du das verstanden?

Marsu65
18.06.2012, 15:57
das Feld eigene_ID ist praktisch der Primärschlüssel, den gibt es nur einmal.
Wenn du bei deinem Aufbau bleibst ja.
Wenn du, wie vorgeschlagen jedoch für jede KW einen Datensatz anlegst, ist das Feld nicht mehr eindeutig.

wird zwar elendig lang das Ding, aber egal (ca 7000 Zeilen für 5 Wochen) naja...
Das sind im Jahr kein 100k Datensätze. Darüber lacht selbst Access. :D
Bis du damit an die 4GB stößt, bist du in Rente ;)

@Anne
nachdem sich Burlie von #19 bis #341 durch Probleme aufgrund der Datenstruktur gekämpft hat, fängt er/sie bei #342 wieder an über das Datenmodell nachzudenken.
:D SCNR

ebs17
18.06.2012, 17:36
Bis du damit an die 4GB stößt, bist du in Rente.
Habe ich eine Revolution verpasst? Eine MDB/ACCDB darf maximal 2GB groß werden.

Bezüglich empfohlenen Feld "KW": Wenn man jahresübergreifend arbeiten will (in einer DB eigentlich selbstverständlich) und Datumsoperationen vornehmen will (1 Quartal betrachten, 1 Monat mit dem gleichen Monat des Vorjahres vergleichen, 2 Monate dazu zählen uva.), sollte man besser einen echten Datumswert für die Tabelle vorsehen, z.B. den Montag der jeweiligen Kalenderwoche.

hinki27
18.06.2012, 19:51
Hallo Burlie,

wenn ich dein Problem und die zwei Screenshots betrachte, würde ich das folgendermaßen lösen. Das ist nicht schnell und elegant, sollte aber mal einen Weg für dein Problem aufzeigen. Dabei ist "DatenXLS" die Eingangstabelle und "Ergebnis" die Zieltabelle mit den Feldern Woche1 bis Woche52 incl den drei Indexfeldern. Bei einem Fehler wegen existierendem Wert gebe ich eine Debugmeldung aus. Die Lösung liegt in der FOR-Schleife, der Rest ist notwendiges übel...


Public Function Datensatz_convert() As String

Dim Conn As New ADODB.Connection
Dim DB1 As New ADODB.Recordset
Dim DB2 As New ADODB.Recordset
Dim x As ADODB.Recordset

Set Conn = CurrentProject.Connection


DB1.Open "Daten_xls", Conn, adOpenStatic, adLockReadOnly
DB2.Open "Ergebnis", Conn, adOpenDynamic, adLockOptimistic

While Not DB1.EOF
If Not (DB2.EOF And DB2.BOF) Then
DB2.MoveFirst
End If
DB2.Filter = "Klasse = '" & DB1!klasse & "' and O = '" & DB1!o & "' and A = " & DB1!a
If DB2.EOF Then
DB2.AddNew
DB2!klasse = DB1!klasse
DB2!o = DB1!o
DB2!a = DB1!a
End If
On Error Resume Next
For i = 3 To 7
If IsNull(DB2("Woche" & DB1.Fields(i).Name)) Then
DB2("Woche" & DB1.Fields(i).Name) = DB1.Fields(i)
Else
Debug.Print "Fehler bei Klasse " & DB1!klasse & ", O " & DB1!o & ", A " & DB1!a & "--> Feld " & "Woche" & DB1.Fields(i).Name & " bereits belegt!"
End If
Next
DB2.Update
DB1.MoveNext
Wend
DB1.Close
DB2.Close
Set Conn = Nothing

End Function

Burlie
19.06.2012, 14:34
Hallo

und Danke an alle Tipps und gut gemeinten Ratschläge.
Werde manches ausprobieren aber eine "echte Datenbank" wird es nie werden, da die Lieferanten immer Excel benutzen und meine Chefs auch Excel Freaks sind. Und da ich in der Firma noch/nur Office 2003 habe muß ich bei diesen Datenzeilenmengen einfach den Umweg Access gehen, denn mit mehreren Tabellenblättern und MegaByte großen Excel zu jonglieren ist auch kake.

Merci an alle.
Bis dänne.