Excel-Tabelle mit vielen Blättern und Daten: Wie mache ich daraus eine Datenbank

Quinn

Quinn

Neuer Benutzer
Beiträge
4
Hallo alle,
das ist mein erster Post und ich habe leider null Ahnung von Datenbanken. Allerdings bin ich durchaus technisch versiert. Dachte ich.

Folgende Problemstellung, kleine Firma, 10 Mann. Alle müssen in der Tabelle schreiben.
ALLE Daten stehen in einer Exceltabelle mit ca. 10 Blättern.

Nun habe ich eruiert das Ganze soll relativ einfach in Access überführt werden können. Gemacht - getan und : Fehlermeldung. Konnte nicht importiert werden weil
- die Titelzeilenfelder nicht übereinstimmen (wie denn auch, es ist ja noch rein gar nix vorhanden?)
- die Tabelle "Blattname" nicht gefunden wurde. Also nur ein Blattname. Was ist mit allen anderen?

Ich gestehe, ich verstehe schon alleine die Fehlermeldungen nicht. Ich hab mich 1:1 an die Internet-Anleitungen gehalten.

Was also muss ich tun, um alle Blätter der Excel Tabelle zu einer funktionierenden Datenbank umzufunktionieren?

Ich bin jetzt nciht auf Access fixiert, ich dachte nur MS-Exel nach MS-Access würde sich anbieten.
 
Werbung:
Access ist nicht super geeignet für Mehrbenutzerbetrieb. Auch wenn ich wegen Excel annehme, dass es nicht viele Datensätze sind.

Da Du nicht schreibst, was die Anleitung vorgibt, sind die Fehler kaum erklärbar.

Grundsätzlich bietet Excel die Möglichkeit, beliebigen Scheiß´in die Zellen zu schreiben. Eines von mehreren Problemen, weswegen man gerne keine Datenhaltung in Excel macht. Datenbank möchten dagegen eine definierte Struktur haben und da knallt es dann mit Excel Daten.
Im Fehlerfall bricht ein Import oder was auch immer Du gemacht hast dann ab. Wenn es gleich am Anfang war, dann ist eben gleich am Anfang Ende.
Ich vermute, Du wirst nicht drum herum kommen, Fehler für Fehler einzeln zu betrachten. Bei der Behebung wird man vermutlich feststellen, dass einige Dinge systematisch sind und man kann alle weiteren Fehler der gleichen Art dann auf einen Schlag beheben.

Wenn Du es mit Access versuchen willst, dann würde ich es über eine Verknüpfung versuchen. Hab allerdings kein aktuelles Access, um da Tipps zu geben.

Ein ganz allgemeiner Weg, um Daten einmalig aus Excel in eine DB zu bekommen, geht über Copy / Paste:
Die Spalten eines Sheets markieren und kopieren und in eine Textdatei einfügen. Die Spalten sind bei diesem Verfahren dann TAB separiert, was die allermeisten Probleme mit Spaltentrennzeichen und Delimitern umgehen sollte, nicht der Standardfall CSV sondern TSV eben.
In der DB Deiner Wahl machst Du dann einen Import dieser Textdatei, mit dem Trennerzeichen TAB.

Meine DB Empfehlung ist Postgres. Der Import einer TSV Datei geht mit dem Befehl
Code: 
\copy neue_tabelle from 'tab_delimited_file' with delimiter E'\t'
Aber egal welche DB Du nimmst, Daten aus Excel zu übernehmen kann beliebig spaßig werden.

Access würde ich mindestens nicht zur Datenhaltung empfehlen.
 
Ok, danke Dir. Ich schaue mir das an. Gibt es vielleicht irgendwo eine Dokumentation über das grundsätzliche Gerüst einer Datenbank? Also was ist es genau, wie funktioniert sie generell, damit ich auch verstehe was ich da mache? Sowas wie „Datenbanken für Dummies“?

Denn das Ziel ist ja, dass jede Änderung überall verfügbar ist. Derzeit muss ich in Excel den Kunden in Blatt a eintragen, und dann natürlich auch in Blatt x weil er ja nicht nur ein Angebot, sondern auch einen Antrag, eine Formular, eine Rechnung bekommt. Die alle eigene Nummern haben etc. Pepe.

Danke Euch!
 
Tja, das Internet ist voll von Tutorials.
Du musst Dich mit Normalisierung beschäftigen. Also einfach ausgedrückt, mit redundanzfreien Datenstrukturen. Vielleicht ist das ja schon jetzt gar nicht so schlecht in Excel.

Zuerst würde ich die Daten 1:1 in die DB laden, pro Sheet eine Tabelle, dann optimieren.
Die Datenänderung geht m.E. mit SQL am einfachsten. Für einen Anfänger ist das aber vielleicht umgekehrt, wenn er sich mit Excel auskennt.

Grob mal zu der "eigenen Nummer":
DB Tabellen haben Primär Schlüssel, eindeutige Nummern um Datensätze zu identifzieren. Andere Tabellen tragen diese Nummern dann als Referenz ein, wenn die Tabelle logisch mit der referenzierten zusammenhängt. In Excel wird sowas meistens über sverweise gebastelt.

Was man nicht verwechseln darf, fachliche Nummern (Rechnungsnummer, usw. ) und Primärschlüssel. Das soll man nie vermischen. Ein technischer Schlüssel soll keinen Zusammenhang mit fachlichen Kriterien haben.

Ich hab mal kurz gegoogelt, es gibt tatsächlich tutorials für Dein Problem (erster Treffer, Englisch), ob es gut ist, weiß ich nicht. Frag einfach, wenn was klemmt:
excel-dashboards.com

Excel Tutorial: How To Convert Excel To Database

Introduction Converting Excel spreadsheets to a database is a crucial skill for anyone working with data. While Excel is a great tool for organizing and analyzing data, it has limitations when it comes to handling large datasets and collaborating with multiple users. In this Excel tutorial, we...
excel-dashboards.com excel-dashboards.com
 
Quinn schrieb:
Das schau ich mir an
Zum Vergrößern anklicken....
Das Tutorial ist ja etwas oberflächlich, aber ein Anfang.
Für Excel Export und Import in die DB noch ein paar Tipps:

- Du solltest einkalkulieren, dass Du ein paar Anläufe brauchst.
Immer mit einer Kopie arbeiten, auch beim wirklich allerletzten Mal.
Beim allerletzten Mal solltest Du zuerst sicherstellen, dass keiner darin arbeitet, die Excelmappe dann readonly machen, dann kopieren, auch readonly machen. Es schadet natürlich nicht, das mit den Kollegen abzustimmen.
- sämtliche Excel-Spalten, die aus Formeln bestehen, exportierst Du nicht
(dokumentarisch kannst Du sie übernehmen, aber in der DB leitest Du sie natürlich neu/anders ab, vor allem speicherst Du sie nicht)
- Achte auf die "natürlichen" Typen der Spalten, Zahl oder Fließkommazahl, Text, Datum, Datum&Zeit.
am besten schon beim Export für einheitliche Formatierung sorgen (ohne Excel Kosmetik mit €, Tausender Formatierung usw.)
- Der Import geht am besten in 2 Schritten:
Importtabelle nur mit hinreichend langen Textspalten (, die genau wie Excel auch den größten Blödsinn an Daten aufnehmen)
Zielstruktur jeweils als Schwestertabelle definieren und mit geeigneten Abfragen aus Import Tabelle auslesen und in Zieltabelle einfügen. Du kannst sämtliche Konvertierungen und Fallunterscheidungen innerhalb dieser Abfragen vornehmen.
- Sicherstellen, dass alle Zeichen (auch exotische) bei der Migration überleben, notfalls einen Testdatensatz dazu eintragen, der diese enthält und prüfbar ist.
- gängige Praxis in Excel: kopierte Sheets mit gleicher Struktur, aber anderes Jahr, anderer Monat, anderer Kunde oder so so was
Das ist ein Nogo in Datenbanken! Und es ist ein gute Übung für die Denkweise "relationale Datenbank", dir zu überlegen, wie man damit in DB umgeht, sprich wie Du 10 kopierte Sheets aus den letzten 10 Geschäftsjahren in eine einzige Zieltabelle bekommst.

Als Tool kann ich DBeaverCE empfehlen, wenn es nichts kosten soll. Das besitzt auch Importassistenten (mit 100en Einstellmöglichkeiten, nicht unbedingt straight forward bzw. weiß man vielleicht später nicht mehr, welche Optionen die waren, die mal funktioniert haben..)

Sinnvoll ist, alles per Script zu machen per Kommandozeile, dann musst Du Dich nie daran erinnern, was wo geklickt werden muss und in welcher Reihenfolge:
a) Exportdateien erzeugen
b) Importscript starten
c) Fehler beheben > im Script per Fallunterscheidung, Konvertierung, ..

b) und c) so oft, bis es durchläuft

Dann ist auch die finale Übernahme kein Stress und geht vermutlich in wenigen Minuten.
 
Ok, ich lese was Du schreibst und versuche es in Nicht-datenbakisches Deutsch zu übersetzen.
:)
Aber im Ernst: Danke für Deine Mühen, ich werde mich damit befassen. Vielleicht hole ich mir tatsächlich das „Datenbanksysteme für Dummies“ Buch, einfach um zu verstehen wie die Logik ist und wie der Aufbau und so weiter.
 
Werbung:
Quinn schrieb:
Vielleicht hole ich mir tatsächlich das „Datenbanksysteme für Dummies“ Buch
Zum Vergrößern anklicken....
Klar, wieso nicht. In meinen Beiträgen hier finden sich allerdings kaum Fachbegriffe. :)
Wie gesagt, fragen, wenn etwas nicht klar ist. Das kann ein Wort sein, eine Formulierung, ein Sachverhalt ein Vorgang, ein unverständlicher Fachbegriff..

Es schadet auch nichts, unabhängig von dem eigenen Vorhaben mal ein Tutorial, ein paar Übungen durchzugehen. Vlt Beispiele aus dem Buch nachvollziehen oder erweiteren oder selbst was ausprobieren.
Das Schöne an DB bzw. an SQL ist, dass man mit sehr wenig Tipp-"Arbeit", kleine Beispiele eingeben / ausprobieren kann, die komplexe SQL Funktionen verständlich darstellen. Eben weil man meist nur 3 -6 Datensätze und 2 oder 3 Spalten benötigt. Alles schnell angelegt und übersichtlich.
 
Zuletzt bearbeitet:
Zurück
Oben