... hier alle zu meinen scheinen, relationale Datenbanken waeren die Loesung des Problems

Vgl. Hugh Darwen und sein "D" als Lern-Umfeld fuer relationales Denken. Hier kostenloses eBook
"An Introduction to Relational Database Theory" und sein "Third Manifesto".

R ist 'ein' Mathematik und Statistik/Datenanalyse/..-Programm.
Es ging darum, Daten mit R auszuwerten - die wie auch immer vorliegen.

Ja, da war ich auf dem falschen Fuss erwischt.

Aber: auch hier gibt es Stolpersteine. Chris Leonard meint "Now I do as little as possible in Excel. This is just one man's opinion, but if you're goal is to analyze data R is much better suited to this task."

Und Micheal Milton meint: "... for every Excel power user there are a hundred people using Excel in a minimal way ... With Excel, loading data and writing formulas is quick and easy. With R, there’s generally some configuration overhead you have to endure in order to start crunching numbers. If you need to do a small handful of descriptive stats on your data, or you need to look something up, run a quick sort/filter, or even a pivot table, Excel is the tool. ... The statistical functions you get in R are much more flexible, numerous, and reliable."

Und Oz du Soleil meint in "Comparing R and Excel Makes No Darn Sense" (womit er so aehnlich denkt wie ich, auch wenn er als Microsoft-Mitarbeiter dafuer bezahlt wird, ich nicht): "Anyone who answers that question is painting their own context around it. Neither is objectively better. Therefore, the question itself needs to provide the context."

Und da sind wir wieder, wo das immer endet: R braucht Kenntnis der Programmiersprache "S", um fuer einen EXCEL-Power-User das zu leisten, was er in EXCEL "ohnehin" kann.

Vgl. "Comparison of data analysis packages: R, Matlab, SciPy, Excel, SAS, SPSS, Stata": (Nachteile) "R: Steep learning curve - Excel: Large datasets".

Und genau darum geht es: die large datasets hat der Controller im SAP-System oder Data Warehouse, auswerten tut er sie mit Crystal Reports oder EXCEL (aber nie in OpenOffice Calc, weil es dann zusammenbricht - und nur darum ging es. Da EXCEL NICHT zusammenbricht, braucht er "R" gar nicht erst lernen. Und: es gibt Anwendungen, in denen R EXCEL unterlegen waere).

Das 'LO/OO/... schlecht' und 'Excel/.. gut', ist mir halt 'zu einfach'.

Schlecht ist OO nicht, habe ich auch nie gesagt. Aber fuer die grossen Mega-Spreadsheets im Controlling eines Grosskonzerns (noch!) nicht leistungsfaehig genug. Beispiel fuer den Groessenwahn: EXCEL hatte lange nur 64k Zeilen, und Calc eine (Sech-) Zehnerpotenz mehr. Dennoch kann OO heute noch nicht, ohne Systemabbruch, alle 64k Zeilen bearbeiten, EXCEL schon, wenn der Computer leistungsfaehig genug ist. Darum allein ging es. Dass R es auch kann, steht ausser Zweifel. Aber: die Grossunternehmen haben seit z.T. zwei Jahrzehnten nunmal z.B. VBA-Makros, deren Portierung auf R aufwendig und nach OO Calc ein Alptraum waere.

Wer sich fuer einen Toyota im Jahr 2005 entscheiden hat und kein neues Auto braucht, kauft erst dann ein neues, wenn er es braucht. Wenn aber ein Bedienmenue eines Autos so komplex waere wie das eines heutige Dialog-Desktop-Programmes, wuerde er die Marke kaum je mehr wechseln.

Und große Datenmengen sind eben IMHO nicht unbedingt der 'Zieleinsatz', für Excel wie OO/LO/...-Calc usw.

Ich redete nicht von grossen Mengen, sondern von komplexen Entscheidungsbaeumen. Dass diese zufaellig auch mengenmaessig gross sind, liegt in der Natur der Sache. Mit "Grosse Datenmengen" in Datenbanken sind aber meist gemeint: unzaehlige gleichstrukturierte (!) Daten. Das ist was anderes. Das muss man aber halt mal mit eigenen Augen gesehen haben. Und dem verweigern sich theoretisierende Naturwissenschaftler stets. Drum steigen sie auch nie ins Controlling auf.

Es sind doch immer noch Zahlen und ggf. Text - und Komplexität ist oft eine Frage von Darstellung

Nein. Komplexitaet ist eine Frage der Darstellung, wenn man einen Kriminalroman schreiben will und dem Leser zwecks Spannung hundert falsche Faehrten legt. Der Controller arbeitet aber mit der geringstmoeglichen Komplexitaet ... und dennoch hat er immer noch Riesen-Spreadsheets. Und wenn man es hundertmal gerne haette: Controller sind weder hilflos noch doof. Gehet hin und dampfet deren Daten ein, statt zu theoretisieren. Viel Spass. Das letzte Mal hatte ich solch eine Diskussion mit einem Blinden ueber Farbe. Nur leider kann ich Braille nicht ins Forum kopieren ...

Was läßt sich denn da nicht mit sicher bisschen abstrakten - und ggf. rekursiven und sonstwie 'verschachtelten' - Datenstrukturen abbilden?

Nein, die sind eben nicht (nur vorhersagbar) rekursiv. Aber Kostenrechnung ist den meisten ein Buch mit sieben Siegeln.

o.k. -- Geht es darum, dass vereinfacht diese 'Modelle' als 'Formeln' und ggf. 'Macros' usw. in den Spreadsheets enthalten sind? Dann müßte man diese Algorithmen natürlich auch abbilden! Mehr dazu unten.

NEIN! Es geht drum, dass diese laufend dynamisch geaendert werden um in Bruchteilen von Minuten zu sehen, "was waere, wenn wir den Preis von Produkt A erhoehen und den von B senken wuerden oder umgekehrt" Und das ueber hunderte Gruppen, Filialen, Standorte, Produktgruppen, Waehrungen mit Umtauschrisiken. Und dann ... mit einem ad hoc eingefuehrten weiteren Produkt, fuer das vorher kein Feld da war. Geht doch einfach mal gucken!!!

Es geht aber primär hier nicht darum WO die Daten gespeichert sind, sondern um die Auswertung der Daten!

Nein, solche Auswertung ist recht statisch. Vgl. Klimamodelle, soziologische Studien wie "alle Paedophilen, die gleichzeitig Erdbeer-Eiscreme bevorzugen, hatten herrische Muetter, die meist vor ihrem 54. Lebensjahr gestorben sind". Das ist einfach. Controller haben einen schwereren Job!

Abstrahiert sind es doch nur irgendwelche Beträge/'Kennzahlen' - die werden mit Algorithmen irgendwie 'verheiratet' - das das komplex ist, bzw. sein kann, stelle ich nicht in Frage+Abrede. Aber warum NUR mit Excel und Excel-Formeln usw.?

Ich hatte Mitte der Neunziger mal eine Diskussion mit einem Dozenten fuer Statistik an einer deutschen Fachhochschule, der mir erklaeren wollte, wie einfach das doch sein muesse, alle zweistelligen Datumsfelder in einer Software zu finden, um sie auf vierstellig umzusetzen (Jahr-2000-Problem). Ich hatte genau so 'ne Probleme, dem das begreiflich zum machen, und gab es auf. So auch hier. Geht hin und schaut's Euch an, zum x-ten Male!!!

Dass es viele mit Excel machen - o.k. - aber warum soll man das nicht anders abbilden (und mit Implementierung auch dynamischer und auch mehrfachen 'Formeln' für jedes 'Datum'/'Zelle'/'Adresse' ist ja wohl auch nicht jedes Mal ein Programmierer erforderlich!

Geh' hin und schau' Dir's an - die einzige Antwort, die mir noch bleibt, ist: wenn das alles anders besser waere, warum, warum machen die brunsdummen Milliarden-Unternehmen es nicht? (Hinweis: das mit dem angucken ist allerdings ganz so einfach nicht; das sind "Staatsgeheimnisse". Da kann man nicht einfach mal so gucken kommen ... Leider. Wer das Spreadsheet klauen duerfte, haette als Konkurrent die Oberhand.)

Controlling bedeuten 'vereinfacht', also im weitesten Sinne, Eingaben und Ausgaben 'im Auge zu haben' und 'gegenzurechnen'.

NEIN! Es geht um die Simulierung, was waere, wenn wir mehr Einnahmen haben wollten als wir derzeit haben. Kostenrechnung ist vergangenheitsbezogen, Controlling auch zukunftsbezogen.

Lenin glaubte 1917 auch, der moderne Grossbetrieb brauche keine Unternehmer mehr, "Buchhalter genuegt". Das kam 1990 zu seinem Ende ...

Beides sind erstmal Differenzen bzw. Summen von anderen Zahlen=Daten -- ggf. mit Schlüsseln='Faktoren' bewertet -- und ggf. auch mit 'Ja/Nein' also Faktor 1/0.

Nein. Aber das zu erklaeren beduerfte es Buecher. Selbst Unternehmensforschung/Operations Research ist komplexer. Aber ein guter Controller hat noch ein paar Ecken mehr zu bieten. Ich habe mehrere solche, leider Kette rauchenden, ausgezehrten verkannten Genies kennen gelernt. Um deren Geschwindigkeit in R und S durch Programmierer zu erreichen, braeuchte der ZEHN Programmierer - dann aber haette er keine Zeit zum Erklaeren oder zum Analysieren. Drum braucht er sein Spreadsheet.

Von mir aus auch beliebig tief, über hierarchische Teilsummen und Teilquotienten, welche dann mit 'Referenzquotienten' (auch dynamisch?!) verglichen werden.

Ja, aber dennoch ist das nicht dasselbe. Es scheint echt schwer, das Sozial- und Naturwissenschaftlern, die Datensaetze immer erst im Nachhinein analysieren und dabei nie unter einem solchen Zeitdruck stehen wie ein Unternehmen im Wettbewerb, zu erlaeutern.

Diese Daten sind an sich natürlich dynamisch - weil eben Geschäftsdaten, die sich halt laufend ergänzen.
Sobald die - sicher beliebig komplexen und wie auch immer rekursiven usw. - 'Formeln' aber einmal 'stehen', ist es 'Datenverarbeitung'.

Nein, der aendert zehn Formeln in der Minute! Das ist von Programmierern ohne Spreadsheet nicht zu leisten. Im Uebrigen nehmen Programmierer oft EXCEL zum Prototyping. Aus selbigem Grunde ...

Ich kann mir ABSOLUT vorstellen, dass ein über Jahrzehnte gewachsenes Rechenmodell - hier auf Basis Excel - NICHT so einfach auf Standardsoftware-'xyz' oder eine Spezialsoftware übertragen werden kann - alles o.k. - aber sobald as EINMAL gemacht wurde

Kann es der Controller nicht mehr schnell genug aendern. Alles schon versucht worden. Und gucke da, im naechsten Monat: "Was machen Sie denn da?" "Ich nehme solange EXCEL, bis die Programmierabteilung meine neuen Anforderungen umgesetzt hat". Vergiss es einfach ...

(und ich rede jetzt nicht von LO/OO/.. sondern z.B. von Werkzeugen wie 'R' die Statistiker/Mathematiker/... nutzen,

Ja, aber Controller nicht ... Selbst in forschenden Unternehmen, wo es jede Menge solcher Eierkoepfe gibt.

oder 'Einzelanfertigung' - und der Aufwand ist so gesehen halt 'NRE'/'NRI' - warum soll das nicht gehen?

Weil es nie flexibel genug ist. Gehe hin und belehre die dortjenigen. Ich glaube es Dir nicht ...

nebenbei: Aus identischen Gründen werden Heute noch FORTRAN-Bilbliotheken (und COBOL usw. z.B. in Finanzsektor) die 30/40++ Jahre alt sind genutzt, weil diee einfach 'stabil laufen' und 'getestet sind'!

Ja, das ist fuer die statischen Berechnungen. Controller nehmen EXCEL.

Es würde also zusammengefaßt darum gehen, ein Software zu entwickeln, die auch hochkomplexe und beliebig 'querverknüfte' Formeln+Macros aus EXCEL 'nachbildet', wie auch seitens der Datenmenge 'per Design' für große Datenmengen ausgelegt ist.

Warum? Es gibt EXCEL schon ...

Warum soll das nicht gehen - also warum soll man keinen Excel-Emulator programmieren können? Und ich behaupte NICHT, dass LO(OO/.. 'sowas' sind!

Aha. Es gibt EXCEL und jetzt willst Du es emulieren?

Ob das 'EXCEL-Nachbilden' jetzt seitens Patentrecht usw. kommerziell umzusetzen ist, ist eine andere Frage -- die nicht Teil der Diskussion ist!

Welche Frage war das? - Das würde mich ersthaft interessieren!

Das war die Frage: "koennen Sie mit ihren Scripting-Kenntnissen bitte mal das nachbilden, was ich in EXCEL in der letzten Minute grade gemacht habe" ... Daraufhin gehen Programmierer dem Controller aus dem Wege.

--
Mit 40 DM pro Kopf begann die Marktwirtschaft, mit 400.000 Euro Schulden pro Kopf wird sie enden.
Atomkraft | in English