Praktische Anwendung einer Datenbank

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).

Lerner schrieb:
> Die Wartungsberichte liegen im PDF Format eingebettet in Emails vor.

Wieviele etwa?

1.000 bis 10.000

Das kann st es ja nicht, unterschiedliche Firmen sind daran beteiligt. 
Daher erst ein,al partiell lösen.

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.

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.

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

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.

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.

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.

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.

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

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.

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.

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? ;-))