Hallo Marino, - wollten wir das nicht auf der business-Liste
diskutieren?-
hier möchte ich doch nun grundsätzlich einhaken:
Bitte keine Gespenster aufbauen!
Am 02.03.2010 18:49, schrieb Marino Salvalaggio:
Hallo Freunde,
ich staune, wie hier die Wogen hochgehen.
Als ich mich vor vielen Jahren mit "Nordwind" befasste, hatte ich
keine Ahnung von der Komplexität einer Datenbank. Ich habe einfach das
Handbuch angefangen durch zu arbeiten und dabei einiges gelernt ;-) .
Genauso ging es mir auch, in habe 1992 mit Access 1.0 angefangen und
habe das / die Handbücher durchgearbeitet und dabei viel gelernt, denn
das Anwenderhandbuch ist / war gut und systematisch aufgebaut.
Ich stammte ja auch einer ganz anderen Gegend der Programmierung und
schrieb damals Assembler für Produktionsanlagen.
Ich bin Jurist und sehe die Aufgabenstellung aus einer anderen -
abstrakteren - Sicht.
Was ich damit sagen will - macht die Sache nicht zu kompliziert!
Ich sehe im Moment nicht, was du damit meinst.
Die Anfänger werden es Euch danken, und eben solche wollen wir doch
gewinnen.
Wenn wir zu hoch schiessen, werden gerade die abgeschreckt, die die
Grundlagen für das Anwenden im kleinen Rahmen benötigen. Später werden
diese selber weiter steigen wollen. Probleme werden auch schon bei
kleinsten Aufgaben offenbar.
So denke ich, dass eine Beispieldatenbank als erstes einfach
grundsätzliche Funktionen demonstrieren sollte. Das bedeutet jedoch,
dass es nicht ausreicht einfach schöne Beispiele ins Netz zu stellen.
Vielmehr wird ein gut strukturierter Begleittext benötigt und hier,
fürchte ich, - ist ja nun eben nicht gerade die Welt von
Programmierern (mich Eingeschlossen)
wird auch der *grosse* Aufwand zu betreiben sein. Ohne einschlägige
Erklärung wird der Neu-User die Funktionen nicht verstehen und
(leider) sehr schnell aufgeben.
Mit Funktionen meinst Du hoffentlich Datenbankfunktionalitäten und nicht
Ereignis- Prozeduren, Routinen, Subroutinen, Module und was es sonst als
Basic- oder sonstige Programmier-Produkte gibt.
Gegenstand einer Beispieldatenbank sollten beispielhafte Darstellungen
von Datenbankfunktionalitäten sein - und die Basis dessen ist die
Erarbeitung des notwendigen Datenmodells. Das heißt, daß eine Sammlung
der benötigten Arten von Daten erfolgen muß und erläutert werden muß,
welche Rolle diese Daten in einer 'richtigen' Datenbank spielen.
Also muß erklärt werden, - was überhaupt ist eine Datenbank.
Da wird man nicht umhin kommen, sich mit dem auseinanderzusetzen, was
viele fälschlich dafür halten, nämlich Kalkulationstabellen in
Programmen, genannt Tabellenkalkulationen.
Diese sind in Wirklichkeit überhaupt keine Datenbanken, sondern ' nur'
Tabellen mit einer Rechenfunktionalität.
In OOo ist das "Calc", und der Begriff umschreibt die Aufgabe des
Programms, nämlich das Rechnen mit Daten im mathematischen Sinn.
Das Konkurrenzprodukt Excel umschreibt mit seinem Namen gleichzeitig den
prinzipiellen Lösungsweg für diese Aufgabe und verfügt insoweit über den
sprechenderen Namen:
EXCEL ist eine Abkürzung und steht -nach meiner Überzeugung- für:
EX_ecutable CEL_ls.
Auf Deutsch: Ausführbare Zellen. Und das genau beschreibt die
Arbeitsweise - aber auch gleichzeitig die Grenzen des Programms:
Jede Zelle der Tabelle ist dazu gedacht, eine Formel zu enthalten, die
sich auf jede andere Zelle der gesamten Tabelle - und damit darin
enthaltene Formeln - beziehen kann. Dadurch werden über Zellbezüge
komplexere Rechenformeln hergestellt, die in vielen Anwendungsbereichen
sicherlich ihren Sinn haben.
Excel und Calc sind reine Rechenprogramme - und reine Datenbestände
haben darin nichts zu suchen.
Solches sind Adressensammlungen mit allen dazugehörigen Daten wie Namen,
Straßennamen, Hausnummern, Postleitzahlen, Ortsnamen,
Telekommunikationsnummern und URLs etc.
Denn - wer will aus diesen Namens- und Textangaben, Telefonnummern
jemals eine Rechenfunktion bilden?
Das ist fast so, als wollte man mit einer Organizer-Rechentabelle einen
Aufsatz schreiben, nur weil sie ggfs. auch Buchstaben darstellen kann.
Solches sind aber auch Buchhaltungsdaten. Denn Buchhaltungsdaten sind
gleichsinnige Datenarten, die immer auf die gleiche Weise in Beziehung
zueinander gesetzt werden und eines individuellen Zellbezuges nicht
bedürfen und eines solchen im Grunde auch nicht zugänglich sind.
Buchhaltungsdaten wie Beträge, Betragsarten, Kostenarten, Konten und
ihre textlichen Bezeichnungen und ihre über Kennziffern zu erfassende
Klasssifizierungen sind stets gleichartig und über den gesamten
Datenbestand in gleicher Weise auch rechnerisch zu verarbeiten.
Zellbezüge, die sich nur individuell, ggfs. in einer Zeile
verwirklichen, sind da nicht denkbar und eine solche Funktionalität ist
da nur kontraproduktiv, weil in erheblichem Maße fehlerträchtig.
Anhand solcher Beispiele muß die konsequente Aufteilung der
Datenbankfunktionalitäten herausgearbeitet werden, die in einen fast
abgeschotteten Datenbereich in Form von Tabellen als zentrales Element
der Datenhaltung und sodann Filter- und Verarbeitungselementen wie
insbesondere den SQL-Abfragebereich aufzuteilen sind.
Alsdann ist die Funktion der Formulare zu erarbeiten, die im
wesentlichen als Eingabemasken dienen und sicherstellen, daß man nicht
versehentlich in der falschen Tabellenzeile etwas verändert, also im
falschen Datensatz - was bei Calc und Excel leicht geschieht. Dazu haben
Formulare eingebaute Sicherungselemente wie Gültigkeitsregeln,
Standardwertmöglichkeiten etc. die man über grafische Elemente leicht
nachvollziehbar einstellen kann.
Insbesondere sind mit Listenfeldern und Unterformulare erhebliche
Eingabeerleichterungen unschwer herstellbar, so daß man stets im
Klartext arbeitet, aber in den wirklichen Daten oft nur Kennziffern
speichert.
Nicht schwer zu erklären ist auch der Bereich der Berichte, die auf ihre
Aufgabe der Gruppierung, Sortierung und Summierung von Daten in
ansprechender Form darzustellen optimiert sind.
Erst danach kommt man zu Notwendigkeiten der Selbstherstellung von
Funktionalitäten durch Basic-Module, aber auch erst dann, wenn SQL nicht
reicht.
Sicherheit als zentrales Element von Datenbanken ist leicht
herauszuarbeiten, man arbeitet NIEMALS direkt in der Datentabelle.
-Was in Calc und Excel ständig geschieht! Ähnliche
Sicherungsmechanismen sind in diesen Rechenprogrammen nur aufwendig
einzuprogrammieren, auch wenn dies durch Hilfsprogrämmchen und
-funktionalitäten etwas einfacher geworden ist.
An der grundsätzlichen Aufgabe von diesen Rechenprogrammen ändert dies
nichts.
Nur ein Datenbankprogramm erzieht zu sauberer Datenhaltung und sichert
diese.
Gerade mit einer Vereinsdatenbank kann man sehr gut relationale
Datenverknüpfungen darstellen und erklären, einige sind hier in der
Liste bereits erwähnt worden. Das ist mit diesen einfachen und für jeden
nachvollziehbaren Datenbeständen in einem Verein mit weithin bekannten
typischen Strukturen gut zu erklären und keineswegs hoch gehängt oder
hoch gegriffen.
Also bitte - nicht dramatisieren!
Ganz wichtig und eine vertrauensbildende Maßnahme ist die Darstellung,
was mit OOo-base nicht bzw. noch nicht geht, und wie man es anders lösen
kann. Dazu sind Fachleute in der Liste, das kann man immer wieder sehen.
Ich halte Andreas Scherbaum's Vorstellung für essentiell, sich mit
diesen wichtigen Leuten zusammenzusetzen - im richtigen Leben-, und dort
die Linie festzulegen.
Im übrigen sollte Mitwirkung interessant bleiben und deshalb niemand im
lehrerhaften Bestimmungston eigene Vorstellungen zum unverrückbaren
Maßstab erklären wollen. Was geht, wird sich zeigen - und wird nicht
befohlen.
Sonst wird die engagierte Mitwirkung still und leise einfach nur
verstummen.
Das Zweit, schon mehrfach erwähnte ist: Der Neu-User sollte für
einfache Anwendungen möglichst schnell Erfolg erleben können. ohne
dise Tatsachen zu berücksichtigen werden wir wohl wieder nur die
Profis befriedigen....
Das ist mit Vorsicht zu genießen, ohne gute Vorbereitung und gemeinsam
erörterte Planung ist ein Erfolg nicht möglich - und schon gar kein
"schneller".
In diesem Sinne - laßt uns den proprietären und profitorientierten
Platzhirschen etwas entgegensetzen, -open source, Offenheit.
Grüße von
Manfred
