Datenbank: Auswertung von Daten

[blake]

Papyrus hat (intern ) die Möglichkeit anzuzeigen, welche Datensätze einer (anderen) Tabelle mit dem aktuellen Datensatz der aktuellen Tabelle verknüpft sind. Beispiel: In Tabelle Kunden kann ich mir für einen Kunden anzeigen lassen, welche Rechnungen ich in der Tabelle Rechnungen an diesen Kunden gesendet habe. In der Tabelle Artikel kann ich mir anzeigen lassen, in welchen Rechnungen der jeweilige Artikel vorkommt.

Naja, das würde ich mir gerne ausgeben lassen! Macht doch Sinn, das ich am Ende des Jahres weiss, welchen Artikel ich wie oft verkauft habe. Noch schöner, wenn ich wüsste, für wieviel € ein Kunde bei mir eingekauft hat. Daher wäre es schön (und aus finanziellen Gründen wichtig), das Papyrus mir (z.B. bei einem Report, aber gerne auch im Datensatz selbst) sagt, WIE OFT der Artikel in einer anderen Tabelle „relationiert“ wurde oder Felder Summieren würde.

Bisher muss ich alles im Report zusammenzählen lassen, und sozusagen von Hand in einer anderen Tabellenkalkulation(szeile) eintragen, um dann evtl. einen Chart/Grafik aud den Daten zu erstellen. (siehe vorheriges Thema)

Das ganze kann man dann als Papyrus BUSINESS vertreiben

[Ulli]

Das läuft letztlich auf m:n Relationen hinaus.

Steht auf der Liste, ist aber nicht so ganz ohne. Mal sehen, wann.

[blake]

Erstmal: Hoffe, der Urlaub war erholsam.

Zweitmal: viele Wege führen nach R.O.M.: (hmm, netter Slogan…)

Es MUSS doch nicht m:n sein: Ein anderer Weg wäre, die einzelnen (zum Ergebnis führenden) Zeilen nicht auszugeben, sondern nur noch die Zeile mit dem Ergebnis (z.B. E12=Sum(E1…E11) führt nur noch zur Ausgabe E12).

Vielleicht geht das ja auch mit den neuen “automatischen” Reports, Das heisst ein erster Report “kaut” alles durch, der zweite zeigt nur die Ergebnisse, der erste wird aber gar nicht erst angezeigt (oder doch, ist eigentlich egal).

Diese Ergebnisse liessen sich dann auch unaufwendiger zur Chart-Erzeugung exportieren.

Die m:n Lösung bietet die Summierung zwar schon im Datensatz selbst an, aber da braucht man sie eigentlich gar nicht, weil man da eigentlich bei der täglichen Arbeit gar nicht hinschaut. Wäre höchstens für eine “Lagerverwaltung” interessant, aber dafür gibts m.E. schon genügend Programme. Für eine statistische Auswertung brauche ich das hingegen nur dann, wenn ich die statistische Auswertung mache. Und nur dann. Und dafür reicht doch der Weg über den Report.

[glucose]

Das läuft letztlich auf m:n Relationen hinaus.

Ich bin mir nicht sicher, ob diese Anwendung bereits m:n-Beziehungen braucht. Ein erster Schritt zur Lösung des Problems könnte aber darin bestehen, die per REPORT() aufrufbaren Reports mit weiteren Parametern versorgen zu können. Diese Parameter könnten dann das Ergebnis von Suchanfragen und damit den generierten Report beeinflussen.

Beispiel:

blake ruft für Kunde X den Report „Jahresbericht“ aus der Tabelle „Kunden“ auf. Dieser zeigt zunächst die wichtigsten Kundendaten an. Im weiteren Verlauf enthält dieser Report einen REPORT()-Aufruf zur Ermittlung der bezogenen Waren und resultierenden Umsätze. Dieser zweite Report bezieht sich auf die Tabelle „Rechnungen“ und benötigt für die Suche der relevanten Daten einen Parameter zur Identifizierung des Kunden sowie das Berichtsjahr.

Steht auf der Liste, ist aber nicht so ganz ohne. Mal sehen, wann.

Als Anregung, wie so etwas gelöst werden kann, würde ich gern auf ActiveRecord verweisen (Bestandteil von Ruby on Rails, einem Framework zur Programmierung von Web-Applikationen).

Eine 1:n-Beziehung definiert man dort so:

class Customer
has_many:slight_smile:invoices)
end

class Invoice
belongs_to:slight_smile:customer)
end

Anschließend kann man im Programmtext beispielsweise über invoice.customer.name auf den Namen eines Kunden zugreifen oder umgekehrt über customer.invoices.count die Anzahl der Rechnungen ermitteln. Elegant daran finde ich die einfache Zuordnung über die Funktionen has_many() und belongs_to(), die sich sehr an die natürliche Sprache anlehnt: Ein Kunde hat viele Rechnungen. Eine Rechnung gehört zu einem Kunden.

Eine m:n-Beziegung würde in einer Variante so aussehen:

class Article
has_many:slight_smile:invoices, :through => :invoice_positions)
end

class Invoice
belongs_to:slight_smile:customer)
has_many:slight_smile:invoice_positions)
has_many:slight_smile:articles, :through => :invoice_positions)
end

und ermöglicht z.B. die einfache Ermittlung aller Rechnungen, in denen ein bestimmter Artikel vorkommt: article.invoices

(Neben den Tabellen „articles“ und „invoices“ muss man dabei natürlich eine Tabelle „invoice_positions“ erzeugen.)

[blake]

Bin leider kein Fachmann, und habe sicher nur die Hälfte verstanden, aber die Hälfte reicht mir schon! Klingt gut! Wann wird das eingebaut?

[dotpap]

Hallo blake,

hallo glucose.

Ich schließe mich glucoses Zweifeln >>Ich bin mir nicht sicher, ob diese Anwendung bereits m:n-Beziehungen braucht.<< an.

Jedoch, das noch etwas „Relationales“ in BASE passieren wird ist klar - eben nur nicht der Zeitpunkt …

Bis dahin kann, und sollte man sich mit unschönen Interselektionstabellen behelfen.

…

Was zu unschönen Arbeiten und überfrachteten Formularen führt, ist der Umstand, dass im Report-Formelfenster es immer noch keinen Zugriff auf alle DB-Felder aller Datenbankentabellen einer Datenbank gibt.Dies sollte meiner Ansicht nach als Nächstes in BASE gelöst werden. Das würde Grenzen sprengen und möglicherweise würde ja auch blake bei dem einen oder anderen Problem geholfen(?).

Die Möglichkeiten von „Meta-Report“ sind offensichtlich gewaltig. Für den, der die Datenbank erstellt ein wahres Eldorado - elegant gekoppelt mit dem Einblenden einer sinnvollen MessageBox hat das schon was.

Ich finde sie haben aber auch einen Nachteil, ein BASE-Anwender, der von Tuten und Blasen keine Ahnung hat, würde mit einer unbedachten Einstellung im Report-Dialog ComboBox „Ausgabe des Reports“ viel Schaden anrichten. Korriegieren könnte er es wahrscheinlich auch nicht. Und auch selbst hat man straff zu tun sich zu merken → welche Reports werden doch gleich angestoßen und mit welchen Hintergrund? Ist damals dieses oder jenes berücksichtigt worden, oder …

Und wenn dann, nach sagen wir zwei Jahren, die Datenbank angepasst werden muss, kann es schmerzlich werden. (Dies ist meine persönliche Befürchtung.)

Siehe auch meine Beiträge, die z.T. dieses Thema hier berühren. Danke.

NOCH BESSER MACHEN

Base Reportfunktion 07.03.08, 15:46 Uhr

NOCH BESSER MACHEN

„Papyrus BASE - ODBC u.ä.“ 06.02.08, 18.07 Uhr