Datenaggregation in einem Netzwerk von Objekten

[Frank (no reg)]

Servus,

ich sinniere momentan über eine Implementierung einer Datenaggregation in einem "Netzwerk" (nein, ich möchte keine TCP/IP Pakete zusammenaddieren).

Vielleicht hat jemand eine Idee, wie man den nachfolgenden Sachverhalt umsetzen könnte (sowohl OO als auch SQL sind möglich):

Gegeben seien die Objekte A, B, C, D, E, F

A gibt C 20 USD
A gibt D 25 EUR
A gibt E 10 JPY (Japanische Yen)

B gibt C 20 USD
B gibt E 30 JPY

A gibt B 40 EUR
F gibt B 20 EUR
F gibt D 25 EUR

Die Währung ist fix pro Empfänger, also B kann nur EUR annehmen, E kann nur JPY annehmen usw.

Und Zirkulärbeziehungen (à la E gibt F 40 EUR) sowie Rückbeziehungen (D gibt A 10 CHF) sind ausgeschlossen.

Als Ergebnis möchte ich jetzt herausbekommen:

• A hat einen Anteil von 20 USD an C (direkt) und 66% von 20 USD an C (indirekt via B), also ingesamt rund 33,33 USD an C.
• A hat einen Anteil von 10 JPY direkt an E sowie 66% von 30 JPY an E indirekt via C also insgeamt 30 JPY an E
• das Wertverhältnis von C und E zu A. Wenn man für USD zu JPY 1:100 annimmt, wären die 30 JPY Anteil gleichwertig 0,30 USD. Damit würden 33,33 USD zu 0,30 USD stehen (99,1% zu 0,9%)

In Sachen Ansatz schwimme ich im Moment gerade noch etwas :)

Also falls jemand eine Idee hat. :)

Ciao, Frank

[Cruz]

Hallo Frank,

ich würde das an deiner Stelle als einen Graphen modellieren.

Datenstruktur in einer Relationalen Datenbank:

Objekt, Typ
B, EUR
C, USD
D, EUR
E, JPY
usw.

Von, An, Wieviel
A, C, 20
A, D, 25
A, E, 10
B, C, 20
usw.

Falls der Wärhrungstyp doch nicht pro Empfänger, sondern pro Transaktion festgelegt wird, was musst du dann machen? :)

Datenstruktur in einem Programm:
Sowas wie eine Hash Tabelle

A -> (C:20, D:25, E:10)
B -> (C:20, E:30)
usw.

Auf dieser Datenstruktur kannst du dann entsprechende Algorithmen implementieren, die dir die gewünschten Werte liefern. Deine Anfrage ist spezifisch genug, dass mir kein Standardalgorithmus dafür bekannt ist, aber wenn dir immer noch nicht ganz klar ist, wie du vorgehen sollst, dann kannst du dir mal den Stoff unter den Stichworten Graphendurchforstung und Netzwerkflüsse reinziehen.

Gruß,
Cruz

[Frank (no reg)]

Hi Cruz!

die Transaktionswährung ergibt sich daraus, was das Empfänger definiert hat. Empfänger nimmt nur USD-> alle Transaktionen dürfen/können  nur USD sein. Es ist eine Beschränkung, die ich als gegeben hinnehmen kann, ohne sie prüfen zu müssen.

Die Relationale Datenstruktur ist gegeben in Form einer Transaktionstabelle, wie du sie auch beschrieben hast (von, an, wieviel (und wann)).

entsprechende Algorithmen

Genau. !! Und genau danach suche ich.

Deshalb danke für die beiden Stichworte :)

Bin momentan am Versuchen, es als loses Netzwerk von "Nodes" zu sehen und die Funktion wie prozentuale Allokation und Summen als Attribute von Objekten zu definieren, die ich dann für jede weitere Transaktion neu berechne.

Ciao, Frank

[King^Lully]

Bin momentan am Versuchen, es als loses Netzwerk von "Nodes" zu sehen und die Funktion wie prozentuale Allokation und Summen als Attribute von Objekten zu definieren, die ich dann für jede weitere Transaktion neu berechne.

Wir raten an hier nicht zu schlau werden zu wollen. Die Datenpflege sollte mit einigen SPs realisiert werden können die Datenanalyse darf U.E. auch mal einen Lauf, einen "manuellen" table scan, beinhalten. Wir wollen erst einmal, dass es funzt und überlassen das Schlauwerden erst einmal den anderen.   ;)

[King^Lully]

Also falls jemand eine Idee hat. :)

Das Datendesign sollte doch klar sein?!

Und dann den DML-Datenzugriff inkl. spezieller Einstellungen formulieren.

Zuallerletzt die Analyselogik.

Oder wo genau ist da Komplexität?

[Frank (no reg)]

Hi King^ Lilly!

Das Datendesign sollte doch klar sein?!

Ja, ist es. Cruz hat es auch schon quasi nochmal beschrieben.

Tabelle Transaktion
Investor       Investment           Amount (Geld, Shares ... Birnen)
-------------------------------------------------------------------
A              B                    30 USD
F              C                    100 JPY

Und dann den DML-Datenzugriff inkl. spezieller Einstellungen formulieren. Zuallerletzt die Analyselogik.

Also so präzise hätt ich's wirklich nicht gebraucht. ;)

Oder wo genau ist da Komplexität?

In der Analyselogik (=Aggregationslogik)???

Vielleicht kannst du ja doch noch etwas konkreter werden mit einer Idee. :)

Danke, Ciao, Frnak

[King^Lully]

Und dann den DML-Datenzugriff inkl. spezieller Einstellungen formulieren. Zuallerletzt die Analyselogik.

Also so präzise hätt ich's wirklich nicht gebraucht. ;)

Du hast doch da einige "Spezialeinstellungen" auf Datentabellenebene, also bestimmte Datensätze (Buchungen) sollen nicht hinzugefügt werden können (bzw. möglich sein). Da kommt man dann typischerweise mit SPs, die genau diese Einstellungen beachten und ggf. Fehlercodes raushauen.

Oder wo genau ist da Komplexität?

In der Analyselogik (=Aggregationslogik)???

Vielleicht kannst du ja doch noch etwas konkreter werden mit einer Idee. :)

Die Anforderung lässt sich anscheinend ganz gut dreiteilen:
1.) Das Datendesign (wurde bereits abgearbeitet)
2.) Die Datenpflege (s.o.)
3.) Das Abfragen der Daten für Zwecke der Geschäftsanalyse

Da wir immer noch keine speziellen Probleme erkennen können (SQL vorausgesetzt ;), halten wir uns leider dem Wunsch nicht entsprechend doch noch ein wenig bedeckt, bis die eigentliche Problematik im Sinne einer Problemisolierung durch den Fragenden herausgearbeitet worden ist.
;)

[Frank (no reg)]

ach .. herrjeeehhh .. :)

Die Datenpflege - Einhaltung von Geschäftsregeln wie ..

• Totalsumme der Investment-Transaktion (kaufe/verkaufe Anteile) muss gleich der Totalsumme der verbundenen Cash-Transaktion sein, sowie deren Valuta-Datum haben
• du kannst nur in ein Investment investieren, wenn du auch ein gleichgerichtetes Währungskonto hast (sprich du kannst nur JPY-basierte Wertpapiere kaufen, wenn du auch in JPY bezahlen kannst)
• und so weiter ...

ist nicht mein Bier, dafür gibt es bereits implementierte Systeme. Nur diese bieten eben keine Analyse über mehrere Investment-Stufen. Genau das brauchen "wir" aber gerade aktuell.

Die Anforderung lässt sich anscheinend ganz gut dreiteilen:

exakt, was "wir" bereits getan haben.

Wie schon zuvor erwähnt habe ich eine Datenmenge der folgenden Struktur:

Investor      Investment      Amount    Datum
-----------------------------------------------------------
A             B               30        2006-12-31
A             B               -5        2007-01-02
A             C               25        2007-01-17
D             B               15        2007-01-17
B             C               40        2007-01-17
B             E               22        2007-01-17

Diese Daten liegen auch exakt so in einer "SQL" Tabelle vor.

Um die Aufgabe (nochmals) zu konkretisieren: Gib mir bitte die prozentuale Investmentverteilung zwischen 1 und n direkten oder indirekten Endpunkten (1. Endpunkt = Root, 2. Endpunkt Leaf), aggregiert für das Root Element.

Also: A investiert direkt in C, indirekt in E. B investiert in C, E. D investiert in C, E.  Welchen Anteil haben C und E in A, B und D.

Wenn du es als SQL Aufgabe sehen möchtest ... kein Problem, soll mir recht sein :) und noch mehr, wenn du eine Idee hast :)

Cheers, Frank

[King^Lully]

ist nicht mein Bier, dafür gibt es bereits implementierte Systeme. Nur diese bieten eben keine Analyse über mehrere Investment-Stufen. Genau das brauchen "wir" aber gerade aktuell.

Werden hier Geschäftsregeln diskutiert, die in externen Systemen implementiert sind und in unserem kleinen System (bspw. ein Subsystem fürs controlling?! ;) nachzubauen sind?
Hoffentlich nicht, also gehen wir mal von hübsch eingepflegten Daten aus, die von uns zu bearbeiten sind.

Investor      Investment      Amount    Datum

A             B               30        2006-12-31
A             B               -5        2007-01-02
A             C               25        2007-01-17
D             B               15        2007-01-17
B             C               40        2007-01-17
B             E               22        2007-01-17

Diese Daten liegen auch exakt so in einer "SQL" Tabelle vor.

Um die Aufgabe (nochmals) zu konkretisieren: Gib mir bitte die prozentuale Investmentverteilung zwischen 1 und n direkten oder indirekten Endpunkten (1. Endpunkt = Root, 2. Endpunkt Leaf), aggregiert für das Root Element.

Also: A investiert direkt in C, indirekt in E. B investiert in C, E. D investiert in C, E.  Welchen Anteil haben C und E in A, B und D.

Wenn du es als SQL Aufgabe sehen möchtest ... kein Problem, soll mir recht sein :) und noch mehr, wenn du eine Idee hast :)

1.Frage: Was spricht gegen Dr.Cursor? (Wenn was dagegen spricht, dann muss die Datenmenge eben mit PHP oder Perl bearbeitet werden.)

[Frank (no reg)]

Werden hier Geschäftsregeln diskutiert, die in externen Systemen implementiert sind und in unserem kleinen System (bspw. ein Subsystem fürs controlling?! ;) nachzubauen sind?

Nein. Nix nachprüfen, einfach nur "berichten". Wir möchten wissen, wieviel Geld aktuell von einem unserer "Investment"-Produkte zu welchen Anteilen in welchen Wertpapieren/Investitionen steckt. -> Reporting

1.Frage: Was spricht gegen Dr.Cursor?

Ganz einfach: es ist arsch-langsam.

(Wenn was dagegen spricht, dann muss die Datenmenge eben mit PHP oder Perl bearbeitet werden.)

Bingo!! ;)

Ciao, Frank

[King^Lully]

1.Frage: Was spricht gegen Dr.Cursor?

Ganz einfach: es ist arsch-langsam.

Wenn Dr.Cursor auf einer konsolidierten lokalen DB losgelassen wird, ist Doc Cursor recht schnell, nicht so schnell wie Doc Holiday oder Doc Snyder, aber immerhin.

(Wenn was dagegen spricht, dann muss die Datenmenge eben mit PHP oder Perl bearbeitet werden.)

Bingo!! ;)

Wenn das Deine Frage war...

[King^Lully]

1.Frage: Was spricht gegen Dr.Cursor?

Ganz einfach: es ist arsch-langsam.

Wenn Dr.Cursor auf einer konsolidierten lokalen DB losgelassen wird, ist Doc Cursor recht schnell, nicht so schnell wie Doc Holiday oder Doc Snyder, aber immerhin.

Ach so, natürlich die DB für den Doc vorbereiten, also eventuell Daten in eine Hilfstabelle setzen und Indizes und so...
(Aber das wissen wir ja alles schon, darum dieser Hinweis nur rein vorsichtshalber.)

[Frank (no reg)]

Also darf ich zusammenfassen:

Du würdest mir eine rekursive (Datenbank)Cursor-Implementierung mit Hilfstabellen und ggf passenden Indizes vorschlagen.

Gut, Danke. :) Das ist doch schon mal ein tiefgehenderer Ansatz als nur über die Datenstruktur oder DML zu sprechen. :)

Ich werde einfach mal schauen, ob ich das mit einem (oder vielleicht mehreren Cursors) in Gang bekomme.

Nochmal Danke, denn du hast mich auch dazu bewegt, meine Probleme (mein Name ist Burkhard und ich habe Probleme ;))  etwas genauer auszuformulieren ;)

Ciao, schön Freitag Abend!
Frank

P.S: sollte es noch darüber Anregungen geben, sind diese willkommen :)

[King^Lully]

Ich werde einfach mal schauen, ob ich das mit einem (oder vielleicht mehreren Cursors) in Gang bekomme.

Also zumindest theorethisch geht das. Erfolgreiche praktische Versuche soll es auch schon gegeben haben.
Klar, es gibt dann auf einmal untypische Laufzeiten von bis zu 60 Minuten, aber früher haben bspw. COBOL-Läufe tagelang gedauert.

P.S: sollte es noch darüber Anregungen geben, sind diese willkommen :)

Du packst alles in ein Perl-Array, beackerst dieses fleissig, erstellst dabei ein XML, das dann mit einer besonders lässigen XSLTransformation als E-Mailanhang dem MA zugestellt wird.
Oder ein DTS-Paket? Alles schän in VBScript kodiert?