Verknüpfung Tabelle-Datenbank

Ich habe hier eine ziemlich große Menge an Daten, die eine recht komplexe Beziehung zueinander haben… (Bereich: Chemie/Produktion). Diese Daten möchte ich nun neu organisieren. Anhand eines einfachen Beispiels möchte ich mein Problem darstellen.

Das Problem: Verwaltung einer Küche; Ziel: Zutaten, Einkauf, Rezepte, Anforderungen an die fertigen Speisen (Spezifikationen) und Bewertung der fertigen Speisen in eine Datenbank (und eine Tabelle??) eingeben, Rezepte suchen, ändern und neu erstellen können, (eventuell statistisch auswerten); Bei Bedarf die mit dem Rezept korrespondierenden Daten (Einkauf, Bewertung usw…) einsehen bzw umgekehrt (von den Einkaufsdaten zum Rezept usw.).

Das Problem dabei ist, in welcher Art werden die Daten wo eingegeben (Tabelle oder Datenbank)? Wie erstellt man einen Zusammenhang zwischen diesen Daten? Der Großteil der Daten eignet sich sicher für relational verknüpfte Datenbank-Tabellen in Papyrus Base. Aber die Rezepte beinhalten mehrere Formeln- Multiplikation jeder einzelnen Menge mit einem Faktor, Darstellung der Gesammtmenge als Summe in der letzten Zeile. Und jede Zutat (z.B.: Mehl-fein) soll direkt aus der Zutatendatenbank bezogen werden; wenn “Mehl-fein” in der Datenbank auf “Mehl-grob” geändert wird, soll sich das natürlich in jedem einzelnen Rezept entsprechend ändern. Ist das Problem überhaupt mit Papyrus lösbar? (wäre MS Excell/Access dafür besser geeignet?)?

Ich habe jetzt schon einige Zeit mit der Papyrus Hilfe verbracht und mit HyperOFFICE-Links herumexperimentiert, jedoch komme ich einfach nicht weiter…

Wie geht man so ein Problem an? Bei welchen Daten sollte man beginnen? Gibt es vielleicht schon ähnliche Datenbanken?

Ich bin für jeden Hinweis dankbar!

Alfred

Hallo alfred.

Deine vorhandenen Daten (Excel-Tabellen) lassen sich nicht nach papyus importieren.

Du stehst somit vor der Aufgabe, jede einzelne Excel-Tabelle in papyrus WORD-Tabellen manuell nachzubilden. Du könntest die Gelegenheit nutzen, um zu prüfen, ob sich nicht mehrere Excel-Tabellen in nur einer papyrus WORD-Tabelle manifestieren können.

Wie auch immer. Manuelle Datenübernahme ist äußerst fehleranfällig. Du solltest jede gefertigte WORD-Tabelle von jemandem überprüfen lassen, ob Datengleichheit besteht.

Eine weitere Aufgabe könnte darin bestehen, eine (oder auch mehrere) Referenz-Tabelle in papyrus WORD zu halten. Diese beinhaltet ALLE Werte, auf die andere papyrus WORD-Tabellen mittels Verknüpfungen zugreifen.

Beispiel:

Ändert sich ein Faktor, den Du in einer Referenztabelle hältst, so könntest Du durch Verknüpfung(en) sicherstellen, dass alle anderen Tabellen die mit diesem Faktor rechnen automatisch diese Änderung übernehmen und Dir beim Aufruf einer solchen Tabelle das aktualisierte Ergebnis angezeigt wird.

Das Ganze kann gern auch recht komplexe Ausmaße annehmen.

Auch hier gilt: Die Formel-Übernahme und Eingabe in die papyrus WORD-Tabellen wäre mit äußerster Sorgfalt vorzunehmen. (z.B. Excel 0,00001 - papyrus WORD-Tabelle 0,0001 = FEHLER)

Auch hier sollte eine akribische Überprüfung auf korrekte Formelübernahme stattfinden.

Es wäre zu beachten, dass papyrus bei erfolgtem Seitenwechsel die Spaltenköpfe einer Tabelle nicht neu zeichnet.

Aufgrund der „Rechenarbeit“ und der „Dynamik“ würde ich nach heutigem Kenntnisstand von einer papyrus BASE-Datenbank eher abraten - machbar ist es. Und das Rechnen in Reports ist auch möglich. (Multiplikation, Summen usw.)

Rechenarbeit - viele Tabellen, viele Formeln, viele Verknüpfungen.

Dynamik - jede einzelne Excel-Tabelle würde quasi mindestens eine Datenbank-Tabelle mit was weis ich wie vielen Report-Vorlagen (Rezept, Bestellung, Labor) erforderlich machen - für den Erschaffer der Datenbank sicherlich noch beherrschbar. Für fremde Anwender, etwa für den Kollegen xyz äußerst problematisch.

Eine abgespeicherte papyrus WORD-Tabelle ist eine ganz „normale“ papyrus-Datei (*.pap).

Sie kann ausgedruck werden.

Du kannst sie per Mausklick zu einer PDF-Datei konvertieren. Sehr gut.

Du kannst sie per Mausklick zu einer RTF-Datei konvertieren. Gut. (ab Version 13.10W)

Der Export nach *.xls ist nicht möglich.

Zusammenfassung:

Also wenn Du es machen willst oder es machen lassen willst …

papyrus WORD-Tabelle:

  1. papyrus WORD-Tabellen 1:1 manuell erstellen. Überprüfung.

  2. Referenztabelle:thumbsdown:. Überprüfung.

  3. Formelübernahme - ggf. Formelanpassung - Formeleingabe, Verknüpfung zu Referenztabelle:thumbsdown: herstellen. Überprüfung.

BASE Datenbank:

Einen Datenbank-Strukturentwurf erstellen. (Formulargröße, Feldnamen, Datentypen, notwendige Tabellen und deren Namen, benötigte Reports und deren aussagekräftigen Namen)

Die BASE-Datenbank auf der Basis des Strukturentwurfs erstellen.

Datenfelder mit Formeln belegen, relat. Verknüpfungen herstellen. Überprüfung.

Formular(e) bearbeiten und designen

Reportvorlage:thumbsdown: - oft je DB-Tabelle - erstellen. (Formeleingabe: Mathematik, Statistik, BASE-Funktionen). Überprüfung.

Hallo dotpap.

Ich verstehe diese kategorischen Aussagen nicht ganz:

(1)

Ja, aber Excel-Tabellen lassen sich doch als csv-Dateien exportieren und werden dann als BASE-Tabellen eingelesen.

(2)

Ja, aber ein Export als ASCII-Datei ist doch möglich, und die kann dann in Excel importiert werden.

Natürlich löst das nicht das Problem der Verknüpfungen und Formeln und des Aufbaus einer komplexen Datenbank, wohl aber hilft es beim Aufbau eines Grundbestandes an Datentabellen in Papyrus. Oder nicht?

Guten Morgen Waldfried!

Aussage (1) bezieht sich auf Excel-Tabellen, welche ich schon an dotpap geschickt hatte. Ich hatte in Bezug auf diese Datenbank schon privat einiges an Mailverkehr mit dotpap. Das Problem bei diesen Excel-Tabellen ist: Es sind sehr viele und sie haben nicht exakt den gleichen Aubau.

Ich dachte mir, vielleicht hat nochjemand ein ähnliches Problem und neue Ideen dazu?

Alfred

Hallo Waldfried.

Ich habe in Klammern “Excel-Tabellen” und die Worte “Import” und “Export” benutzt.

Und: ich habe darauf hingewiesen, dass der Import der (Excel-Tabellen) nach papyrus genau so wenig möglich ist, wie der Export einer papyrus WORD-Tabelle nach Excel.

IMPORT

xls (Excel Spreadsheet) | xlsx (Excel Spreadsheet Microsoft® Excel 2007)

papyrus besitzt keinen Import-Filter für xls | xlsx-Dateien. Somit kann keines dieser Dateiformate nach papyrus importiert werden.

EXPORT

xls (Excel Spreadsheet) | xlsx (Excel Spreadsheet Microsoft® Excel 2007)

papyrus besitzt keinen Export-Filter für xls | xlsx-Dateien. Somit kann papyrus diese Dateien nicht erzeugen und exportieren.

Das ist in der Tat eine kategorische Aussage - mir scheint sie korrekt zu sein.

Wenn Du bspw. eine *.doc-Datei nach papyrus importierst, erwartest Du doch von papyrus, dass es dir mittels eines vorhandenen leistungsstarken Filters die *.doc-Datei so konvertiert, dass Du sie in papyrus-Umgebung verlustfrei betrachten, aber auch bearbeiten und abspeichern kannst - entweder als *.pap oder als *.doc-Datei. Das gibt es in papyrus und papyrus wird diesbezüglich im leistungsfähiger …

Die gleiche Erwartungshaltung dürfte sich aufbauen, wenn es also bspw. um *.xls-Dateien geht.

Nur hier gibt es nun mal bekannterweise in papyrus keinen Import/Export-Filter.

Das Gesagte trifft in diesem Zusammenhang umgekehrt für den Export zu.

Das strukturierte Einlesen/Auslesen (CSV, …) der Daten aus einer Excel-Tabelle nach papyrus BASE und zurück, verstehe ich nicht unter Import/Export im Sinne des oben Gesagten.

Diese Vorgehensweise kann sich von Fall zu Fall anbieten, wenn Daten relativ eindeutig und zuordnungsbar sind. (Etwa wenn Excel, wie so oft, als Adressen-Datenbank missbraucht wurde.)

In der wohl überwiegenden Zahl der Fälle - so auch bei alfred - kann also von dieser Vorgehensweise kein Gebrauch gemacht werden.

Hallo Alfred,

Ich habe den Eindruck, dass Dir hierzu noch grundlegendes Wissen zu relationalen Datenbanken fehlt, insbesondere über die Normalisierung von Daten, 1:n-Beziehungen und n:m-Beziehungen sowie deren Auflösung. Diese Themen sind nicht schwer zu verstehen, aber man muss sich dazu ein wenig belesen, um die gewünschte Datenbank sinnvoll aufbauen zu können. Vielleicht findest Du bei Gelegenheit einige Anleitungen im Netz (im Umfeld von MySQL oder Postgres sollte etwas zu finden sein). Ich selbst habe diese Dinge mit Hilfe eines Buches über relationale Datenbanken gelernt.

Für die reine Datensammlung und -organisation hat Papyrus eigentlich alle notwendigen Funktionen. Um sich mit der Sache vertraut zu machen, kann man ohne weiteres damit anfangen. Problematischer wird es erst bei der komplexen Auswertung der Daten und ggf. auch bei der Bedienbarkeit einer solchen Datenbank. Wenn man an diesem Punkt angekommen ist und merkt, dass es mit Papyrus nicht mehr weiter geht, kann man die Daten aber relativ problemlos exportieren, sofern sie auch in Papyrus vorausschauend angelegt worden sind.

Beginne mit einem einfachen, überschaubaren Problem, das ganz am Anfang Deiner Prozesskette steht. Damit schaffst Du die Grundlage für Erweiterungen zu den nachfolgenden Schritten. Da es um Rezepturen geht, die typischerweise aus verschiedenen Stoffen oder Substanzen bestehen, müssen diese zunächst mal beschafft bzw. eingekauft werden. Am Anfang würde ich also den Beschaffungsprozess sehen.

Ein Beispiel für eine solche Beschaffungsdatenbank befindet sich im Anhang dieses Beitrags. Es handelt sich dabei um eine Datenbank, die ich selbst fast täglich verwende, um Bestellungen per Fax zu erzeugen oder auch um Online-Bestellungen zu erfassen (allerdings habe ich den Großteil der Daten verständlicherweise gelöscht)

Aufbau der Datenbank

Es gibt 7 Tabellen:

Produkte

Liste der benötigten Produkte, Stoffe, Substanzen

Lieferanten

Liste der Lieferanten, ihrer Adressen und unserer Kundennummer beim jeweiligen Lieferant

Sortiment

Hier werden Produkte und Lieferanten zusammengeführt. Jeder Datensatz in dieser Tabelle verknüpft ein Produkt mit einem passenden Lieferanten und speichert ggf. die entsprechende Artikelnummer, Verpackungseinheit und Preis. Ein Produkt kann dabei mehrfach in dieser Tabelle auftauchen, z.B. weil ein Lieferant hierfür mehrere Verpackungseinheiten anbietet oder weil das Produkt von mehreren Lieferanten erhältlich ist. Im Datenbankjargon wird hier eine m:n-Beziehung abgebildet (m Produkte werden mit n Lieferanten verknüpft).

Klassen

Hier sind mögliche Lieferantenklassen aufgelistet. Den Lieferanten kann eine Klasse zugeordnet werden, um sie als Hauptlieferant, Ausweichlieferant oder sonstiger Lieferant zu kennzeichnen. Diese Klassifizierung wird in der Tabelle Sortiment eingetragen.

Einheiten

Eine Liste möglicher Einheiten, also kg, g, Stück etc. Die Einheiten werden für die Bestellpositionen verwendet.

Bestellungen

Hier werden alle Bestellungen eingetragen, nummeriert und mit einem Lieferanten verknüpft (1:n-Beziehung). Außerdem ist die Festlegung eines Liefertermins sowie von Liefer- und Zahlungsbedingungen möglich.

Bestellpositionen

Jeder Bestellung kann hier eine beliebige Anzahl Bestellpositionen zugeordnet werden. Es wird also die Nummer der Bestellung mit Einträgen aus der Sortimentstabelle verknüpft.

Bedienung der Datenbank

Sofern Produkte, Lieferanten und Sortiment eingetragen sind, ist die Erstellung einer neuen Bestellung relativ einfach:

  1. In der Tabelle Bestellungen wird ein neuer Datensatz angelegt. Dabei wird die Bestellungsnummer automatisch um eins erhöht und das aktuelle Datum eingetragen. Es muss der Lieferant ausgewählt und ggf. Liefer- und Zahlungsbedingungen sowie der gewünschte Liefertermin festgelegt werden. Im Feld Bestelltext kann man bei Bedarf beliebige Texte eingeben, was bei manchen Bestellungen erforderlich sein kann, die sich nicht streng an einem bestimmten Sortimentskatalog ortientieren.

Nach Bestätigung der Daten erzeugt man den Report „Bestellung-Fax“ und bekommt einen ausgefüllten Briefkopf mit Lieferantenadresse, Datum, Bestellungsnummer, Kundennummer, Liefertermin, etc.

  1. In der Tabelle Bestellpositionen legt man fest, was eigentlich bestellt werden soll. Für jede Position legt man einen neuen Datensatz an und verknüpft diesen mit der Bestellung und mit einem Sortimentseintrag. Nach Festlegung der Menge berechnet ein solcher Datensatz automatisch den Gesamtpreis für diese Position, wobei auf den Einzelpreis aus der Sortimentstabelle zurückgegriffen wird. Der Einzelpreis kann aber auch manuell abgeändert werden, falls es kurzfristig zu Preisänderungen gekommen ist.

Wenn alle Bestellpositionen festgelegt sind, markiert man diese im Tabellenfenster und ruft den Report „Bestellpositionen-Tabelle“ auf. Dieser wird direkt in den unter (1) erzeugten Vordruck eingefügt. Vor dem Einfügen sollte man deshalb ggf. den Textcursor im Vordruck an die richtige Stelle setzen. Die eingefügte Tabelle der Bestellpositionen berechnet automatisch die Gesamtsumme über alle Positionen, Mehrwertsteuer und den Gesamtbetrag.

Danach kann man die Bestellung noch manuell verändern oder einfach abspeichern, ausdrucken und auf’s Fax legen.

Schau Dir die Datenbank genau an und versuche zu verstehen, wie ihre einzelnen Bestandteile miteinander verknüpft sind. Probiere ein paar eigene Produkte, Lieferanten und Sortimentspositionen einzutragen und daraus eine Bestellung zu generieren. Wenn diese Beziehungen und Vorgänge einigermaßen klar sind, kann es an die Erweiterung in Richtung Rezepturerfassung gehen.

Viel Spaß

beschaffung-demo.zip (23.2 KB)

Hallo Glucose!

Danke für die Beispieldatenbank- ich werde sie mir genau ansehen (das kann etwas dauern). Ich glaube, sie passt teilweise recht gut zu meinem Problem.

Alfred

Hallo dotpap und Alfred,

nachträglich besten Dank für die ausführlichen Erläuterungen.

Zitat alfred:

Das habe ich vermutet, konnte es aber nicht wissen, wurde von dotpap leider nicht dazugesagt in seinem “ersten” Beitrag. (A propos: Macht deine neue Datenbank Fortschritte, Alfred?)

Zitat dotpap (meine Hervorhebungen):

Verstehe. Ich wüsste nun noch ganz gern explizit, was konkret verloren geht. Ich nehme an, dass es darum geht, dass nicht mehrere Tabellen einer DB gleichzeitig und mitsamt ihren Verknüpfungen portiert werden können.

Hallo Waldfried.

Ich habe versucht deutlich zu machen, dass das Auslesen der Daten aus einer Excel-Tabelle nach CSV wohl öfters kein Allheilmittel ist. In der Tat gehen z.B. Formeln verloren. Aber es gibt auch oft Excel-Tabellen deren Erschaffer ohne Spalten- und Zeilenbeschriftungen gearbeitet haben, sie haben hier ein paar Felder mit Werten und da noch einige und ganz unten befindet sich auch noch einges an unkommentierten Zahlen … Was bitte nutzt mir da das Auslesen dieser “kryptischen Zahlenwerte” nach CSV und das Einlesen in eine papyrus BASE-Tabelle. Schon allein die Zuordnung der Spalten im BASE-Import-Dialog gestaltet sich da abenteuerlich.

Es gibt aber auch Excel-Tabellen (Datenaufkommen), da ist das ohne Probleme möglich. (Z.B. eine Excel-Tabelle mit Adressen …)

Danke für die rasche Antwort, Gerd.

Logisch, wenn die Quell-Daten schlecht bzw. problematisch sind, ist auch die Portierung problematisch.

Waldfried

13.06M, 10.5.3