Hallo, einmal vorweg: ich habe keinerlei Erfahrungen mit Datenbanken, möchte aber etwas Praxiserfahrung bekommen. Ich will z.B. aus Wartungsberichten der letzen Jahre Material Verbräuche erfassen. Die Wartungsberichte liegen im PDF Format eingebettet in Emails vor. Was brauche ich dazu? Ein riesiges käufliches Produkt kommt nicht in frage.
Lerner schrieb: > Die Wartungsberichte liegen im PDF Format eingebettet in Emails vor. > > Was brauche ich dazu? Viel Geduld, viel ungünstiger gehts eigentlich nicht mehr. Teile dein Problem in Unterschritte 1. PDF aus den Mails extrahieren 2. Den notwendigen Text aus dem PDF extrahieren Wo dieser Text dann landet ist erst mal ziemlich egal, ob das jetzt eine Text oder XML Datei ist oder eine Datenbank. Das Problem ist das PDF Format. PDF ist eigentlich ein Textsatzsystem, das Textfragmente seitenorientiert positioniert. Die eigentlichen Nutzdaten (der Text) kann dann sogar noch komprimiert vorliegen. Vieleicht kennt ja jemand hier ein Tool das den Text halbwegs zuverlässig extrahieren kann.
Nachtrag: Eine je nach Kenntnissen machbare lowtech Lösung könnte sein die Berichte auszudrucken und mit OCR (Texterkennungsssoftware) einzuscannen.
*.eml hat so einiges zu bieten bis du das PDF da herausbekommst. Dokumentiert und standardisiert ist es, es halten sich natürlich nicht alle dran. Viel Spaß damit ! PDF kannst Du mit pdftk auseinandernehmen oder dir die Doku von Adobe runterladen. Das Auseinanderpflücken ist, da sich Adobe an seinen Standard hält, nicht so wild.
Wundere Dich nicht, wenn Du am Ende ein paar graue Haare findest. Das Problem ist mehrteilig. Hast Du z.B. die Daten nicht im O-Ton (Dateien), sondern nur auf Papier, so geht der Ärger schon los. Natürlich einscannen! Aber die aktuellen OCRs erreichen ihre, doch bemerkenswert gute Erkennungsrate, nur durch die Verwendung von Wörterbüchern. Etwas, was beim Einscannen von Tabellen nicht viel, oder Garnichts, hilft. Hier stellt sich neben der Frage wie gut die Vorlangen sind auch die Frage: Wie viele Fehler dürfen es denn sein? Ääm? Wenn Du praktisch jede Zahl "persönlich" überprüfen musst, kannst Du sie auch gleich eintippen. Mit Logik lässt sich hier auch nicht viel machen, da beim OCR-Lesen aus 100 nicht 100000 wird sondern vielleicht 106, 700 oder so. Oops! Grundsätzlich tun sich OCRs schwer mit dem Erkennen von "gut" formatierten Tabellen. Oft ist sehr viel "Handarbeit" im Vorfeld nötig. Hast Du das Formular dann - mit viel Mühe - in einem Maschinenlesbaren Format, so stellt sich auch gleich die nächste Frage: Wie viele Änderungen am Format hat es im gewünschten Zeitraum gegeben. Die automatisierte Verarbeitung setzt ein Format voraus, das immer gleich ist. Nochmal Oops! Jetzt kommt das Unangenehmste. Du musst entscheiden, welche Datenbank Du verwenden willst. Sonderwünsche z.B. hierbei sind: Die soll es noch morgen geben; möglichst nicht nur von Dir verwendet sein; möglichst noch mehr Tools zum Datenaustausch. Solltest Du andere wegen der besten Datenbank fragen, so darfst Du Dich nicht wundern, wenn Du von 5 Leuten 6 verschiedene Antworten bekommst oder 5-mal die Gleiche (man kennt sich ja).
Das hatte sich ch mir schon so gedacht, graue Haare habe ich schon... Die PDF Formulare sehen durchaus unterschiedlich aus. Was aber nicht schlimm ist. Ich muss nach 7 bis 8 stelligen Zahlen suchen. Die sind aber bekannt. Die PDF Dateien will ich alle in einen Ordner speichern und dann auswerten.
Lerner schrieb: > Ich muss nach 7 bis 8 stelligen Zahlen suchen. Das Problem bei PDF ist das ein String, hier "7-8 Zahlen", nicht unbedingt als ein String im Dokument gespeichert sind. Das Können auch zwei Stringobjekte sein die halt hintereinander platziert wurden. Nur so als Warnung was da auf dich zukommen kann (aber nicht muss).
Teilweise ( zB CorelDraw) auch einzelne Zeichen mit Koordinaten.
Lerner schrieb: > Die Wartungsberichte liegen im PDF Format eingebettet in Emails vor. Wieviele etwa?
Alle identisch aufgebaut? Wir haben mal das selbe Problem mit Kontoauszügen gehabt. Die Lösung war 4000 von Hand abtippen. Ging mit mehreren Menschen dann doch ganz gut und zügig. Wichtig, egal wie du die Daten einpflegt wirst, überlege dir Kontrollen, die mögliche Fehler aufdecken. Z.b. alle Positionen der Rechnung summieren und mit der ausgelesenen Summe vergleichen.
wenn die 10k PDFs aus dem gleichen System kommen ist das schon eher realisierbar. Mit pdftk Textauszüge erstellen und die dann auswerten. Da sollte dann ein ähnliches Muster erkennbar sein.
Das kann st es ja nicht, unterschiedliche Firmen sind daran beteiligt. Daher erst ein,al partiell lösen.
Worum geht es hier wirklich? - Gesucht wird eine Datenbank, erfasst wird manuell? - Gesucht wird eine automatische Erfassung in eine bestehende DB?
:
Bearbeitet durch User
bei 10k Dokumenten mit ziemlicher Sicherheit um etwas "automatisches". Eine Datenquelle (bzw Firma) spuckt vermutlich die PDFs mehr oder weniger gleich aus. Dann halt mehrere Importfilter. Ist ja kein Hexenwerk (wenn sich das auseinanderhalten läßt).
A. K. schrieb: > Worum geht es hier wirklich? > - Gesucht wird eine Datenbank, erfasst wird manuell? > - Gesucht wird eine automatische Erfassung in eine bestehende DB? Fange bitte bei #1 an zu lesen. Dann muss ich es nicht mehrfach erklären.
Udo S. schrieb: > Nachtrag: Eine je nach Kenntnissen machbare lowtech Lösung könnte > sein > die Berichte auszudrucken und mit OCR (Texterkennungsssoftware) > einzuscannen. Ausdrucken ist definitiv nicht noetig. Bei Zahlen bleibt die Erkennungsproblematik: hier ein Fallbeispiel wo es um Telefonnummern, Zeiten und Kosten geht. Es macht eben einen Unterschied ob ein Telefonat als 0.89 oder 8.90 Waehrungseinheiten kostend erkannt wurde. Beitrag "Knacknuss Text aus PDF extrahieren" Dieses Fallbeispiel zeigt auch dass es sehr wohl PDFs gibt welche sehr einfach gestrickt am Bildschirm u. Ausgedruckt aussehen, aber deren Inhalt keinesfalls sich als Text extrahieren laesst.
Lerner schrieb: > Fange bitte bei #1 an zu lesen. Dann muss ich es nicht mehrfach > erklären. Ganz schön arrogant dafür daß eine Frage nach einer Datenbank gestellt wird obwohl eigentlich eine Extraktion von Daten aus PDF Dateien das eigentliche Problem ist. Lerner schrieb: > Hallo, einmal vorweg: ich habe keinerlei Erfahrungen mit Datenbanken, > möchte aber etwas Praxiserfahrung bekommen. Das ist dann wohl eher geschwindelt (nett gesagt), denn bei 10000 Dokumenten steht da garantiert ein gewerbliches Interesse dahinter. Sorry ich bin hier raus!
Leo K. P. schrieb: > Dieses Fallbeispiel zeigt auch dass es sehr wohl PDFs gibt welche sehr > einfach gestrickt am Bildschirm u. Ausgedruckt aussehen, aber deren > Inhalt keinesfalls sich als Text extrahieren laesst. Genau deshalb ist bei solch üblen PDFs ja ein Ausdrucken und einscannen ein evt. vielversprechenderer Weg. Du widersprichst dir irgendwie selber :-)
Udo S. schrieb: > Leo K. P. schrieb: >> Dieses Fallbeispiel zeigt auch dass es sehr wohl PDFs gibt welche sehr >> einfach gestrickt am Bildschirm u. Ausgedruckt aussehen, aber deren >> Inhalt keinesfalls sich als Text extrahieren laesst. > > Genau deshalb ist bei solch üblen PDFs ja ein Ausdrucken und einscannen > ein evt. vielversprechenderer Weg. Du widersprichst dir irgendwie selber > :-) Schusselig formuliert, sorry. Versuch2: es gibt PDFs woraus sich Textinhalt nur indirekt via OCR rekonstruieren laesst, keinesfalls direkt als (ASCII, UTF-8)Text extrahieren laesst.
Lerner schrieb: > Die Wartungsberichte liegen im PDF Format eingebettet in Emails vor. > > Was brauche ich dazu? Ein paar Inder. Ernsthaft mit ein paar günstigen Arbeitskräften irgendwo im Ausland könnte es gehen. Es gibt sogar Diensteanbieter, die sich darauf spezialisiert haben so eine Sizzifuss Arbeit online anzubieten, im Gegensatz dazu kriegen diejenigen, die die Arbeit machen irgendwelche Coins oder Geld, die sie dann einlösen und sich damit etwas kaufen können. In so manchem Land kann sich das für die rechnen. Der Haken an der Sache ist nur, dass so manche Coins auch dafür gedacht waren, dass die irgendwo für z.B. Keys für Computerspiele eingelöst wurden. Manche Kinder haben da also sicherlich auch mit gemacht um Punkte zu sammeln und damit hättest du dann Kinderarbeit finanziert und das willst du sicherlich nicht. Insofern solltest du dir diese Art von Diensteanbieter sehr genau ansehen. Ein Haken ist hier auch, dass du deine Daten natürlich rausgeben würdest. Bezüglich einer technischen Lösung kommt es darauf an, wie die Daten vorliegen. Bei manchen PDF Dateien können die Daten nochmals eingebettet als XML Daten eingebettet sein. Das wäre eine sehr gute Ausgangslage, da man so etwas relativ leicht extrahieren kann. ZUGFeRD nutzt so etwas bspw.. Siehe dazu auch: https://de.wikipedia.org/wiki/ZUGFeRD Wenn die Daten im PDF als Text vorliegen, dürfte auch noch eine Extraktion möglich sein. Richtig blöd wird es, wenn der Text in den PDFs nur Rastergrafiken sind. Dann wirst du einen OCR Software benötigen, dir dir das wieder in gut verarbeitbaren Text umwandelt. Hier kann der Vorschlag, die Sachen zuerst auszudrucken und dann wieder einzuscannen Sinn machen, da man sich so Arbeit sparen könnte. Wenn die Datenmenge klein ist, dann kannst du die Daten natürlich auch manuell übertragen. Wenn du die Daten dann endlich als bspw. ASCII oder UTF-8 Text vorliegen hast, gibt es viele Möglichkeiten. Z.b. könntest du dir ein Script schreiben oder eine Tabellenkalkulation nutzen. Ein Datenbankmanagementsystem ist dafür sicherlich noch nicht erforderlich.
Leo K. P. schrieb: > Versuch2: es gibt PDFs woraus sich Textinhalt nur indirekt via OCR > rekonstruieren laesst, keinesfalls direkt als (ASCII, UTF-8)Text > extrahieren laesst. Da sind wir uns ja einig. :-) Genau deshalb war ja mein Vorschlag, wenns nicht klappt die Texte zu extrahieren, dass man ausdruckt und einscannt und mit OCR versucht die Daten zu bekommen. Das irgendwelche Witzbolde das neagtiv bewerten zeigt nur dass sie wohl noch nie mit wirklich üblen PDFs zu tun hatten :-)
Udo S. schrieb: > Genau deshalb ist bei solch üblen PDFs ja ein Ausdrucken und einscannen > ein evt. vielversprechenderer Weg. Wenn das die Greta liest, dann hast du nichts mehr zu lachen! Leute wir wissen nicht, wie die PDFs genau ausschauen. Deswegen ist es auch komplett sinnlos hier die wildesten Theorien zu erdenken. Der TO soll erstmal ein paar einfache Sachen wie "pdftotext" ausprobieren und uns das Ergebnis mitteilen.
Udo S. schrieb: > Leo K. P. schrieb: >> Versuch2: es gibt PDFs woraus sich Textinhalt nur indirekt via OCR >> rekonstruieren laesst, keinesfalls direkt als (ASCII, UTF-8)Text >> extrahieren laesst. > > Da sind wir uns ja einig. :-) Genau deshalb war ja mein Vorschlag, wenns > nicht klappt die Texte zu extrahieren, dass man ausdruckt und einscannt > und mit OCR versucht die Daten zu bekommen. > > Das irgendwelche Witzbolde das neagtiv bewerten zeigt nur dass sie wohl > noch nie mit wirklich üblen PDFs zu tun hatten :-) Da im Computer bei "Anzeigen am Bildschirm" und im Drucker "auf Papier bringen" der Renderingvorgang gleichartig ablaeuft, ist es fuer den "OCR-Weg" nicht noetig Material (Papier) zu verschleissen. Die Pixelwueste worin die OCR-Magie (Buchstabenerkennung) stattfindet, kann also statt von Papier via Scanner, direkt von entsprechender SW ins RAM generiert werden. Nur weil OCR drauf steht, muss das nicht nur von Papier weg gemacht werden. PDF --> convert --> tesseract --> ASCII
Für gutartige PDFs (das sind >95% in meinem Fundus) kommt man mit "pdftotext" recht weit. Das ist ein Begleiter des "xpdf" Readers, der auf unixoiden Betriebssystemen weit verbreitet ist. (oder war?) Mittlerweile ist es Teil der poppler-utils (unter Debian).
Was hat das Ganze mit "einer Datenbank" zu tun? A. K. schrieb: > Worum geht es hier wirklich? > - Gesucht wird eine Datenbank, erfasst wird manuell? > - Gesucht wird eine automatische Erfassung in eine bestehende DB? Ich finde diese Frage durchaus angemessen. Leider wurde sie nicht beantwortet.
Lerner schrieb: > 1.000 bis 10.000 Naja, das ist eben etwas unspezifisch. Bei 1.000 Berichten setzt man eine Aushilfskraft etwa 3 bis 4 Wochen hin, die das in ein Excelsheet reinhämmert. Problem günstig und schnell gelöst. Bei 10.000 Berichten muss man es anderes machen, will man nicht ewig warten und/oder einen Haufen Geld ausgeben: Die PDFs anonymisieren und entsprechend vorbereiten, so dass sie mit einem Dienst wie Microtask, Mechanical Turk, ClickWorker, CloudCrowd, und wie sie alle heißen, zum Fraß vorgeworfen werden können. Irgendwo ab zwischen 50.000 und 1.000.000 Berichte engagiert man eine Software-Klitsche die ein angepasstes System baut.
Interessierter schrieb: > Bei 1.000 Berichten setzt man eine Aushilfskraft etwa 3 bis 4 Wochen > hin, die das in ein Excelsheet reinhämmert. Problem günstig und schnell > gelöst. gelöst??? Dann hat man das gleiche Problem mit dem Kack Excel. Daten gehören in ein passendes wiederverwendbares Format und niemals in Excel.
Lerner schrieb: > A. K. schrieb: >> Worum geht es hier wirklich? >> - Gesucht wird eine Datenbank, erfasst wird manuell? >> - Gesucht wird eine automatische Erfassung in eine bestehende DB? > > Fange bitte bei #1 an zu lesen. Dann muss ich es nicht mehrfach > erklären. Deine Beiden Annahmen sind falsch! Datenbank gesucht---> ja Manuelle Erfassung?---> falsch Bestehende Datenbank?---> nein Automatische Erfassung?---> im Peinzip wird nichts neu erfasst, die PDFs liegen ja vor. Wir es jetzt klarer?
Lerner schrieb: > Automatische Erfassung?---> im Peinzip wird nichts neu erfasst, die PDFs > liegen ja vor. Liegen die Daten in einem verwendbaren Format vor? Nein Sind die Daten in einer Datenbank? Nein. Das heißt sie müssen erfaßt werden. Genauer genommen, erst müssen sie aus dem PDF heraus konvertiert werden. Ich würde sagen, sogar mit Fehlerkontrolle. Also ist schon das eine Neuerfassung.
T.roll schrieb: > Wenn das die Greta liest Meine Güte, fällt euch nix besseres ein, als euch an einem kleinen Mädchen abzuarbeiten? Keine Argumente? Nur ein einfallsloser Versuch andere herabzuwürdigen? Mann, geh in deine Garage und nimm mal einen ordentlichen Schluck aus deinem Auspuff, dann gehts dir vieleicht wieder besser.
Lerner schrieb: > Hallo, einmal vorweg: ich habe keinerlei Erfahrungen mit Datenbanken, > möchte aber etwas Praxiserfahrung bekommen. > > > Ich will z.B. aus Wartungsberichten der letzen Jahre Material Verbräuche > erfassen. > > Die Wartungsberichte liegen im PDF Format eingebettet in Emails vor. > > Was brauche ich dazu? Ein riesiges käufliches Produkt kommt nicht in > frage. Ich habe sowas mit Apache Tika gemacht. Allerdings eingebunden in ein Java-Projekt. Du kannst aber auf die Schnelle Deine PDFs Tika vorwerfen und schauen, was dabei rauskommt. https://tika.apache.org/ Tabellenerkennung ist noch nicht dabei, eventuell hilft das hier: https://tabula.technology/
Als Datenbank empfehle ich für den Anfang MariaDB. Die ist kostenlos und handlich. Lass dich beim Programmieren durch diverse Frameworks nur nicht dazu verleiten, verschachtelte Transaktionen zu benutzen, denn die unterstützt MariaDB nicht wirklich. Falls du mit dem Begriff "verschachtelte Transaktionen" nicht anfangen kannst, dann ist diese Einschränkung für dich vermutlich irrelevant.
T.roll (Gast) schrieb: >Interessierter schrieb: >> Bei 1.000 Berichten setzt man eine Aushilfskraft etwa 3 bis 4 Wochen >> hin, die das in ein Excelsheet reinhämmert. Problem günstig und schnell >> gelöst. >gelöst??? Dann hat man das gleiche Problem mit dem Kack Excel. Daten >gehören in ein passendes wiederverwendbares Format und niemals in Excel. Dann exportiere es doch als csv. Läßt sich in jede Datenbank importieren ... Lerner (Gast): >Datenbank gesucht---> ja >Manuelle Erfassung?---> falsch >Bestehende Datenbank?---> nein >Automatische Erfassung?---> im Peinzip wird nichts neu erfasst, die PDFs liegen ja vor. Du willst also die PDFs pur "as is" in einer DB speichern? Also als BLOB? Ohne weiteres drumherum, oder irgendwelche Auswertemöglichkeiten der PDF-Daten? Wozu braucht man da eine DB? Stefanus F. schrieb: >Falls du mit dem Begriff "verschachtelte Transaktionen" nicht anfangen >kannst, dann ist diese Einschränkung für dich vermutlich irrelevant. Wozu erwähnst Du das überhaupt. Meinst Du, er macht sich in diesem Stadium bereits über fortgeschrittene Konzepte einer DB einen Kopf?
:
Bearbeitet durch User
Jens G. schrieb: > T.roll (Gast) schrieb: > >>Interessierter schrieb: >>> Bei 1.000 Berichten setzt man eine Aushilfskraft etwa 3 bis 4 Wochen >>> hin, die das in ein Excelsheet reinhämmert. Problem günstig und schnell >>> gelöst. > >>gelöst??? Dann hat man das gleiche Problem mit dem Kack Excel. Daten >>gehören in ein passendes wiederverwendbares Format und niemals in Excel. > > Dann exportiere es doch als csv. Läßt sich in jede Datenbank importieren > ... Was für ne Logik! Erst die Daten also in einem schrottigen Excel speichern um sie dann in ein vernünftiges CSV zu exportieren. Ein Hoch auf die deutsche IT-Landschaft.........
Udo S. schrieb: > Nachtrag: Eine je nach Kenntnissen machbare lowtech Lösung könnte sein > die Berichte auszudrucken und mit OCR (Texterkennungsssoftware) > einzuscannen. Wie schräg ist das denn :O Wenn das Greta erfährt.
Jens G. schrieb: > Wozu erwähnst Du das überhaupt. Weil das der größte Schwachpunkt von MariaDB (auch MySQL) ist. Wer damit kein Problem hat, für den kann das eine richtig gute Datenbank sein.
Gibt es keine kleinen Datenbanken zu spielen und Erfahrungen zu sammeln? Vielleicht nur 10 Datensätze groß. Und mit der man probieren kann ob PDF Formulare einlösbar sind?
Lerner schrieb: > Gibt es keine kleinen Datenbanken zu spielen und Erfahrungen zu sammeln? Ja sicher doch. MariaDB ist eine kleine Datenbank. Vielleicht sogar die kleinste. > mit der man probieren kann ob PDF Formulare einlösbar sind? Eine Datenbank wird aber nicht den Inhalt von PDF Dateien interpretieren können. Woher soll die Datenbank wissen, welche Wörter und Zahlen aus dem PDF von Interesse sind und was sie bedeuten? Du musst schon selbst ein Programm schrieben, dass die gewünschten Daten aus den PDF Dokumenten extrahiert.
Stefanus F. schrieb: > Ja sicher doch. MariaDB ist eine kleine Datenbank. Vielleicht sogar die > kleinste. MariaDB ist nicht klein, keine DB sondern ein waschechtes DBMS und wenn der Fragende ein Volldau ist, was man an seinen Fragen erkennt, fährt er mir anderen Produkten einfacher. Wenn es klein sein soll nimmt man sqlite und muss sich nicht Benutzern und Rechten rumplagen und das Backup ist auch am einfachsten oder auch csv und importiert das in Excel, damit kommt der DAU üblicherweise einfacher zurecht und reicht für so single-table Aktionen die er vor hat. Später kann er das immer noch in eine richtige DB importieren. Daten extrahiert man pdf2text pdfgrep und 100.000 anderen Tools. Wenn man nicht völlig geistig behindert ist, also google bedienen kann wie heute jedes 10 jähriges Kinde, findet man das alles nach 3s in Google.
Franko S. schrieb: > MariaDB ist nicht klein, keine DB sondern ein waschechtes DBMS Bevor ihr euch jetzt gegenseitig den Frack vollhaut, guckt euch mal diesen Vergleich an: https://db-engines.com/de/system/MariaDB%3BSQLite
Franko S. schrieb: > Wenn es klein sein soll nimmt man sqlite Stimmt, sqllite ist wesentlich schlanker als MariaDB. Hatte ich gar nicht mehr auf dem Schirm.
Man sollte doch die Frage stellen, warum der TO meint, eine Datenbank zu benötigen? Vieles läßt sich doch auch direkt mit Excel lösen? Das Problem der Datenerfassung ist davon unabhängig.
Eddy C. schrieb: > Vieles läßt sich doch auch direkt mit Excel lösen? Excel ist hier aus irgendeinem Grund Tabu. Wann immer ich Excel vorschlage, bekomme ich mindestens viele Minusse, manchmal auch kräftigen Gegenwind.
Eddy C. schrieb: > Man sollte doch die Frage stellen, warum der TO meint, eine Datenbank zu > benötigen? Das wurde bereite vor einigen Stunden gefragt. Mit dieser Antwort: Lerner schrieb: > A. K. schrieb: >> Worum geht es hier wirklich? >> - Gesucht wird eine Datenbank, erfasst wird manuell? >> - Gesucht wird eine automatische Erfassung in eine bestehende DB? > > Fange bitte bei #1 an zu lesen. Dann muss ich es nicht mehrfach > erklären. NichtWichtig schrieb: > Wenn das Greta erfährt. Der nächste, der sich von einem kleinen Mädchen in die Ecke gedrängt fühlt.
Stefanus F. schrieb: > Eddy C. schrieb: >> Vieles läßt sich doch auch direkt mit Excel lösen? > > Excel ist hier aus irgendeinem Grund Tabu. Wann immer ich Excel > vorschlage, bekomme ich mindestens viele Minusse, manchmal auch > kräftigen Gegenwind. Er könnte auch Libre Calc verwenden. Die Daten könnte er darin auch als csv importieren.
Stefanus F. schrieb: > Excel ist hier aus irgendeinem Grund Tabu. Wann immer ich Excel > vorschlage, bekomme ich mindestens viele Minusse, manchmal auch > kräftigen Gegenwind. Weil Excel eine verdammte (und schreckliche) TABELLENKALKULATION ist und keine Datenbank! Da kloppt man Zahlen in eine Tabelle und rechnet mit diesen. Daten gehören, wer hätte es gedacht, in eine DATENBANK. Nochmal ganz einfach: EXCEL != DATENBANK Udo S. schrieb: > Meine Güte, fällt euch nix besseres ein, als euch an einem kleinen > Mädchen abzuarbeiten? Keine Argumente? > Nur ein einfallsloser Versuch andere herabzuwürdigen? > Mann, geh in deine Garage und nimm mal einen ordentlichen Schluck aus > deinem Auspuff, dann gehts dir vieleicht wieder besser. Udo S. schrieb: > Der nächste, der sich von einem kleinen Mädchen in die Ecke gedrängt > fühlt. Immer noch am pöbeln? Vergiss nicht am Freitag zu demonstrieren und dann mit dem SUV nach Hause zu fahren. Oder wie wärs mit einer netten Kreuzfahrt? https://www.wetter.de/cms/schulklasse-geht-auf-kreuzfahrt-schueler-verbrauchen-das-halbe-co2-jahresbudget-4406067.html
T.roll (Gast) >Weil Excel eine verdammte (und schreckliche) TABELLENKALKULATION ist und >keine Datenbank! Da kloppt man Zahlen in eine Tabelle und rechnet mit >diesen. Daten gehören, wer hätte es gedacht, in eine DATENBANK. >Nochmal ganz einfach: EXCEL != DATENBANK Wenn interessiert das? Den TO offensichtlich nicht, denn er braucht ja scheinbar keine Datenbankfunktionalität, sondern offensichtlich nur etwas, wo er seine PDFs reinwerfen kann. Ein simples Filesystem reicht da schon für das, was er uns an Anforderungen so preisgibt.
Wenn du so viele Dokumente inkl. OCR und "Verschlagwortung" zu verwalten hast, solltest du über ein Dokumentenmanagement-System (DMS) nachdenken. Die gibts für ordentlich Geld (mit Service und Garantie), aber auch als Open Source, zum Teil rein web-basiert (PHP, MySQL), d.h. man kann sie z.B. auf einem NAS aufsetzen (z.B. QNAP oder Synology), zum Teil aber auch als "gewöhnliche" Anwendung für Desktop- oder Server-Betriebssysteme. Von einigen DMS gibts sog. "Community-Versionen" kostenlos und mit gewissen Einschränkungen im Funktionsumfang, z.B. "BitFarm". Wenn du unbedingt etwas in überschaubarer Zeit selber stemmen willst, schau dir mal die Software Filemaker Pro an. Das ist eine Desktop-Datenbank mit grafischer Oberfläche u. Scriptprogrammierung. Es gibt auch einen Server für den zentralen Netzwerkbetrieb (Win u. Mac), der kostet aber ordentlich. Filemaker Pro gibt es auch als kostenlose iOS-Version "FilemakerGo". Wenn man den FM Server benutzt, kann dieser die GUI der Datenbanken als Webserver publizieren ...
Wir wissen ja nicht mal was er genau mit den Daten vor hat aber so wie sich das anhört hat er tausende identisch struturierte PDFs und will die handvoll Spalten inne Tabelle haben, das bischen Auswertung drumherum geht mit Excel einfacher und schnelller als mit jeder DB, da ist Excel als DB Ersatz genau richtig und Excel ist auf jedem Bürorechner und kann auch jeder einigermassen bedienen. for i in * do alles=$(pdftotext -raw "$i" - 2 >/dev/null) # Da schaut man mal rein was da was wie ausgegeben wird und passt den # regexp an, evt. ist -m1 fällig oder man filter noch mit head # oder nimmt gleich awk je nach Geschmack,... datum=$(echo "$alles" | grep -P -m1 nach_datum|sed -r ...) auftragsnummer=$(echo "$alles" | grep nach_Auftragsnummer|sed ...) whatever=.... echo "$datum;$auftragsnummer;..." >> alle_pdfs.csv done Man kann auch mal vorher checken ob die Bilder enthalten (pdfimage) und in denen der relvante Text drinn steht, den dann durch ein ocr jagen. So habe ich mal über 5000 Wahlzettel nachträglich ausgewertet, geht alles.
Das ich keine Ahnung von diesem Projekt habe schrieb ich bereits. In der Zeitlinie Vergangenheit bis Gegenwart habe ich unterschiedliche PDF Strukturen gefunden. Ob ich die auch verwenden will weiß ich noch nicht, in der ersten Phase jedenfalls nicht. Die neueren lassen sich in ein Textfile ohne Verluste kopieren. Dazu habe ich auf der Seite alles markiert und kopiert. Die PDFs liegen jeweils als Anhang in einer Mail vor.
Gehe das Schrittweise an. Zuerst musst du die benötigten Daten aus einem PDF extrahieren und z.B. einfach nur auf dem Bildschirm auflisten. Danach automatisierst du das mit vielen PDF Dateien. Dann machst du dich eventuell daran, die Email automatisch auszulesen. Dann besorgst du eine Datenbank und speicherst die extrahierten Daten dort . Dann kümmerst du dich um die Verarbeitung der Daten, den Reports.
Stefanus F. schrieb: > Gehe das Schrittweise an. > > Zuerst musst du die benötigten Daten aus einem PDF extrahieren und z.B. > einfach nur auf dem Bildschirm auflisten. > > Danach automatisierst du das mit vielen PDF Dateien. > > Dann machst du dich eventuell daran, die Email automatisch auszulesen. > > Dann besorgst du eine Datenbank und speicherst die extrahierten Daten > dort . > > Dann kümmerst du dich um die Verarbeitung der Daten, den Reports. Warum muss man die Daten aus einem PDF "extrahieren"? Finde ich doppelt gemoppelt. Einfach die PDFs durch ein vernünftiges OCR jagen und daraus den Index für die Volltextsuche und die Verschlagwortung bilden, diese in eine Datenbank. Das PDF ebenfalls. Bei Bedarf das PDF (nach entsprechender Suche) samt Text-Suchergebis anzeigen ... DMS eben.
Frank E. schrieb: > Warum muss man die Daten aus einem PDF "extrahieren"? Finde ich doppelt > gemoppelt. > > Einfach die PDFs durch ein vernünftiges OCR jagen und daraus den Index > für die Volltextsuche und die Verschlagwortung bilden Damit extrahierst du die Daten. Mit welcher Methode das geschehen wird, kann ich schlecht abschätzen. Denn ich habe noch kein solches PDF gesehen. OCR würde ich nur anwenden, wenn das PDF ein gescanntes Dokument (also ein Bild) ist. Normalerweise würde ich erwarten, dass das PDF Dokuemtn die Daten in textform enthält, und dann kann die bereits oben empfohlene Umwandlung in Text schon hilfreich sein. Oder man benutzt eine Bilbiothek für das Parsen von PDF. Das habe ich mal in Java genutzt, war gar nicht schwer.
PDF: xref laden, dann die objects herausziehen, dekodieren und mal schauen was da so drinnen ist. Ist kein Hexenwerk. Dann die Kenndaten finden, isolieren und nach sqlite speichern.
Ja. Nimm eine MySQL Datenbank auf einer Linuxmaschine. zB auf einem Backup Server wie einer Synology, oder einem Webserver.
Frank E. schrieb: > Warum muss man die Daten aus einem PDF "extrahieren"? Finde ich doppelt > gemoppelt. > > Einfach die PDFs durch ein vernünftiges OCR jagen Das ist doch die Extraktion der Daten? Was glaubst du denn, was andere mit "Extraktion" meinen? Und OCR ist aufwendig (langsam, teuer). Wenn die Daten mal Text waren, stehen die Chancen gut, daß sie auch direkt als Text extrahierbar sind, ohne den Weg über eine Pixelwüste (und sei es nur in einem Framebuffer) gehen zu müssen. > und daraus den Index > für die Volltextsuche und die Verschlagwortung bilden, diese in eine > Datenbank. Selbst wenn die Rohdaten als Text vorliegen, kann das immer noch eine Herausforderung sein. Wenn ich den TE richtig verstehe, sind das tabellarische Daten. Die würde man dann schon in Zeilen und Spalten zerlegen wollen und dann strukturiert abspeichern. > Bei Bedarf das PDF (nach entsprechender > Suche) samt Text-Suchergebis anzeigen ... DMS eben. Für eine Volltextsuche auf einem Sammelsurium an PDF Files braucht man keine extra Datenbank. Die kann man auch gleich im Filesystem indizieren. Hat Windows da nicht sogar Bordmittel dafür (Dateisuche)?
Joggel E. schrieb: > Ja. Nimm eine MySQL Datenbank auf einer Linuxmaschine. zB auf > einem > Backup Server wie einer Synology, oder einem Webserver. Aha. Und dann? Sucht er über das Terminal mit SQL-Staements nach den Daten aus einen PDF-Dateien? Das ist ja, als wenn jemand ein Auto sucht und du empfiehlst ihm, er möge doch zwei Räder nehmen und einen Besenstiel durchstecken ... dann könne er balancieren. Es ist mir rätselhaft, wieso hier so viele Mitforisten immer nur zu Bruchstücken oder irgenwelchem Gefriemel raten, wenn es doch zumindest fahrbereite Kleinwagen fertig und umsonst gibt (aka Open-Source DMS). Was soll das?
Axel S. schrieb: > Frank E. schrieb: >> Warum muss man die Daten aus einem PDF "extrahieren"? Finde ich doppelt >> gemoppelt. >> >> Einfach die PDFs durch ein vernünftiges OCR jagen > > Das ist doch die Extraktion der Daten? Was glaubst du denn, was andere > mit "Extraktion" meinen? Und OCR ist aufwendig (langsam, teuer). Ok, unter Extraktion verstehe ICH, die Durchsuchung der PDF-Struktur nach Textobjekten und deren direktes Herauslesen. Das geht aber in der Realität genau so oft schief, wie OCR, weil die interne Struktur des PDF oft nichts oder nur wenig mit dem optischen Aussehen zu tun hat. Das sieht man z.B., wenn man aus einem im PDF-Reader geöffneten Dokument per Cut&Paste Textblöcke entnehmen will - da hat man oft nur Bruchstücke des Textes "am Haken" oder mittendrin Textblöcke, die aus völlig anderen Bereichen des PDF stammen ... Deshalb würde ich immer auch das Originaldokument direkt oder per Link in der Datenbank unterbringen und Zusätzlich die per OCR und direkter Extraktion gewonnenen Textfragmente als Suchindex. So macht das jedenfalls jedes halbwegs erwachsene DSM.
Erst einmal nachdenken, dann handeln. a) Zuerst muß sich der TE Gedanken über die Daten und deren Struktur machen. b) Ferner muß geklärt werden, welche Fragen man an die Datenbank stellen möchte. c) Jetzt den Datenbanktyp wählen. Viele glauben, daß es nur relationale Datenbanken gibt... ;-) d) Wenn der Typ feststeht, dann kann ein konkretes Produkt ausgesucht werden. Das kann dann z.B. auch OSS sein. e) Dann müssen die Daten extrahiert und in die DB exportiert werden, wenn es ganz dumm läuft auch noch kategorisiert. Wenn die PDFs beispielsweise eingescannt handgeschriebene Wartungszettel sind, dann wird es lustig. Es kann gut sein, daß eine automatische Datenerfassung gar nicht möglich ist. Viele Projekte scheitern, weil mit irgendeiner DB spontan begonnen wird und der Annahme "der Rest findet sich später". Später stellt sich dann oft heraus, daß mit der angelegten Datenstruktur die gewünschten Abfragen gar nicht möglich oder unrealistisch aufwendig sind. Und es gibt Fälle, in denen dann mit der unbrauchbaren Lösung weitergearbeitet wird, "weil doch schon so viel Arbeitskraft investiert wurde".
svensson schrieb: > Und es gibt Fälle, in denen dann mit der unbrauchbaren Lösung > weitergearbeitet wird, "weil doch schon so viel Arbeitskraft > investiert wurde". Der alltägliche Wahnsinn im Büroalltag - besonders in Behörden.
Dann rate doch einmal, wo ich diese Erfahrungen gemacht habe? ;-))
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.