Tabellenkalkulationsmodelle

Die Kriterien für "gute" Tabellenkalkulationsmodelle sind Gegenstand dieses Kapitels. Es werden die unterschiedlichen Typen von Tabellenkalkulationsmodellen angeführt und die unterschiedlichen Rollen, in denen Personen mit derartigen Modellen arbeiten, typisiert. Aus der Kombination von Typ des Modells und Rolle leiten sich dann auch die konkreten Anforderungen ab, wie das Modell im Einzelfall optimal gestaltet werden kann.

Formularmodell

Der erste Grundtyp eines Tabellenkalkulationsmodells beschäftigt sich mit EINEM Objekt; es werden z. B. die Kosten eines Auftrags, die Rentabilität eines Investitionsprojekts, die Höhe der Einkommensteuer einer Person oder auch die Höhe der Studiengebühr einer/eines Studierenden berechnet.

Wir verwenden auch hier ein sehr einfaches Modell, das den MUSSS-Beitrag für ein Modul "Besser Schwindeln" errechnen soll. Das Modul weist 6 ECTS-Punkte auf, je ECTS-Punkt sind 12 € zu bezahlen. Mit dazu kann ein Buch "Optimal Schwindeln" in 7 Lektionen zum Hörerscheinpreis von 36 € erworben werden. Der Hörerscheinpreis steht allen MUSSS-Teilnehmer/inne/n automatisch zu. Für Bestellungen vor dem 14. September eines Jahres werden 10% Einführungsrabatt (auf den Gesamtbetrag bezogen) abgezogen.

Wenn Sie eine solche Aufgabenstellung lesen, sollte Ihnen klar sein, dass es sich hier um den Typ eines "Formularmodells" handelt. Ein Formular hat typischerweise Felder, in die man etwas eintragen muss - aus Sicht der Programmierung sind das die Inputvariablen. Diese Inputvariablen sind im vorliegenden Fall:

• Buch gewünscht (J/N): Der Datentyp dieser Eingabe ist ein Wahrheitswert - es kann nur ja oder nein als Antwort geben.
• Datum der Bestellung: Davon hängt ab, ob der Einführungsrabatt abzuziehen ist oder nicht.

Da das Datum der Bestellung automatisch durch das Programm bereitgestellt wird, verbleibt im konkreten Fall nur ein einziges Eingabefeld; wir haben also das "kleinstmögliche" Modell vor uns - und können das auf zwei völlig unterschiedliche Arten lösen:

Bei beiden Lösungsvarianten sind alle erforderlichen Beziehungen durch Formeln abgebildet - rein von den Formeln her besteht zwischen beiden Modellen doch ein Unterschied, der Ihnen hoffentlich auffällt:

• Lösung A ist wie ein Papiertaschentuch - einmal gebraucht und dann wegzuwerfen. Wenn jemand anderer dieses Modell erhält, dann braucht er wahrscheinlich genau so lange, es zu verstehen wie es neu zu machen - und das wird Ihnen selbst auch nicht anders gehen, wenn Sie das Modell nach einem Monat wieder öffnen. Es lohnt sich gar nicht, ein solches Modell überhaupt zu speichern - es ist ein "Wegwerfmodell". Auch Wegwerfmodelle können ausnahmsweise sinnvoll sein - aber Ausnahmen bestätigen nur die Regel, dass solche Lösungen nicht zweckmäßig sind.
• Lösung B dagegen ist deutlich übersichtlicher aufgebaut - und der Aufbau sollte ziemlich selbsterklärend sein. Der Endanwender des Modells kann nur eine Zelle eingeben - und daher sind alle anderen Zellen geschützt. Zur visuellen Kennzeichnung des Eingabefeldes ist dieses hier grau unterlegt. Das ist in diesem Fall ein geeignetes Attribut, kann aber in anderen Fällen unzweckmäßig sein, wenn dadurch ein "Fleckerlteppich" entsteht. Bei vielen Eingabefeldern wird daher ein dezenteres Attribut zur Kennzeichnung der Eingabefelder angezeigt sein.
  • In dieser Eingabe ist zudem eine Gültigkeitsprüfung definiert; es sind nur die Werte Ja und Nein eingebbar, die zudem in einer Auswahlliste angezeigt werden
  • Bei der Formel in A6 sieht man zudem, dass die KostenJeECTS als Name angelegt wurden. Der Preis ist zwar laut Angabe fix - eine spätere Änderung aber wohl nicht auszuschließen. Durch die hier gewählte Vorgangsweise muss nur der Zellschutz deaktiviert, die entsprechende Zahl und der Konfigurationstabelle geändert und der Zellschutz wieder aktiviert werden.
  • Ebenso ist dies beim Preis des Buches passiert - auch hier wurde ein Name verwendet. Der Preis ist dabei sowohl im Textfeld in Zelle B7 wie auch in der Formel in A6 durch den Namen repräsentiert.
  • Die Tabelle mit den beiden Angaben, die zwar für den Endanwender derzeit fix sind, aber für Modelländerungen leicht anpassbar sein sollen, ist in einem anderen Segment der Tabelle untergebracht - daher auch die Verwendung von Namen. Solche Werte, die das Verhalten des Modells steuern, werden oft als "Systemparameter" oder "Konfigurationsdaten" bezeichnet. Auch solche Systemparameter sollten nie fix in Formeln eingegeben werden, sondern durch Bezüge auf Zellen einbezogen werden.
  • Die Tabelle ist auch so aufgebaut, dass die Kalkulation für mehrere unterschiedliche Module angepasst werden kann. Es kommt dann einfach die Modulbezeichnung als zweites Eingabefeld hinzu.

Auch wenn unser Beispiel so einfach wie möglich ist, sehen Sie daran die wesentlichen Kriterien für Formlarmodelle:

• Klarer Aufbau, der der Denklogik den Endanwenders folgt
• Visuelle Signalisierung von Eingabezellen
• Gültigkeitsprüfung von Eingaben, wenn nur bestimmte Wertebereiche zulässig
• Schutz von Zellen vor unbeabsichtigter bzw. versehentlicher Eingabe
• Auslagerung von Systemparametern abseits des Modells, mit sprechenden Namen aber dynamisch in das Modell eingebaut.

Ein paar Hinweise noch zu Faktoren, die aufgrund der Einfachheit des Modells nicht vorgekommen sind:

• Neben einer übersichtlichen Darstellung am Bildschirm sollten Sie auch auf eine entsprechende Darstellung am Drucker zu achten. Denken Sie daran: Nicht jede/r hat vielleicht einen so großen Bildschirm wie Sie am Desktop ihn möglicherweise besitzen - und vielleicht trifft das schon Sie selbst bei der Arbeit auf einem Notebook! Bevor Sie ein Modell als "fertig" ansehen, erstellen Sie stets einen PDF-Dokument und kontrollieren Sie, ob ihr Modell auch dann noch den richtigen "Eindruck" macht.
• Sind die Anweisungen für Eingabefelder komplizierter als es der Platz am Formular erlaubt(und Zeilenumbruch allein nicht reicht), können sie auch Kommentare hinterlegen; das gilt ebenso für komplizierte Formeln, die sonst nur langwierig durchschaubar sind.

Listenmodell

Ein Listenmodell haben Sie schon kennengelernt: Unser Beispiel in Abschnitt Analysieren als Entscheidungsvorbereitung - Wie sonst? war ein Listenmodell.

Listenmodelle enthalten viele gleichartige Objekte, die typischerweise zeilenweise aufgebaut sind. Listenmodelle weisen daher eine gewisse Verwandtschaft zu jenen Daten auf, die typischerweise in Datenbanken gespeichert sind.

Der Vorteil von Tabellenkalkulationsmodellen ist dabei, dass es flexiblere Möglichkeiten der Auswertung und Analyse der Daten gibt als dies mit üblichen Datenbankabfragesprachen möglich ist. Vielfach werden Daten daher zwar in Datenbanken verwaltet - aber in Tabellenkalkulationsprogrammen ausgewertet. Viele Daten zu verwalten, ist nämlich die Stärke von Datenbanken. Tabellenkalkulationsprogramme zur Verwaltung von Daten einzusetzen wird nur ausnahmsweise sinnvoll sein.

Für Listenmodelle ist daher auch der Datenaustausch zwischen Datenbank und Tabellenkalkulation eine ganz wesentliche Voraussetzung. Die dafür erforderlichen Dateiformate haben Sie bereits kennen gelernt.

Der Aufbau von Listenmodellen ist weitgehend durch die Spaltengliederung vorgegeben. Wichtig ist in diesem Zusammenhang eine entsprechende Formatierung, die sowohl am Bildschirm wie auch am Drucker zu einer übersichtlichen Darstellung führt. Instrumente dazu sind insbesondere:

• Die Festlegung passender Spaltenbreiten; durch die Verwendung schmaler Fonts und Zeilenumbrüchen in Textfeldern kann eine sinnvolle Breitenbegrenzung erreicht werden.
• Überschriften sollten - durch Teilung des Fensters und Fixierung des Überschriftsbereichs sowohl am Bildschirm wie auch am Drucker (Drucktitel) auf jeder Seite sichtbar sein.
• Beim Drucklayout bietet sich üblicherweise eine Formatierung auf Querformat an.

Auch bei Listenmodellen kann die Aktivierung des Zellschutzes sowie die Gültigkeitsprüfung von Eingabewerten zweckmäßig sein. Ein besonders interessantes Feature in Zusammenhang mit Listenmodellen ist die "Bedingte Formatierung". Man kann damit interessante Abweichungen bzw. Zustände einzelner Zellen bzw. Zellbereiche höchst effektiv visuell ersichtlich machen.

Vielfach werden bei Listenmodellen den eingegebenen bzw. aus Datenbanken importieren Daten noch zusätzliche Spalten durch Berechungsvorgänge hinzugefügt. Dafür sind in aller Regel Systemparameter erforderlich. Wenn die Liste nach unten wachsen können soll, dann bietet es sich an, diese Systemparameter auf ein eigenes Tabellenblatt auszulagern. Wenn es sich um sehr wenige Daten handelt, können die Daten ggf. im Bereich über der Liste angeordnet (und beim Druckbereich außer Acht gelassen)werden.

Typischerweise finden sich auf Listenmodellen auch noch zusätzliche Auswertungen; im einfachsten Fall nur die Summe einzelner Spalten. Normalerweise sind aber Auswertungen enthalten, die sich nicht auf die gesamte Liste beziehen, sondern nur auf (einen oder mehrere) Teilbereiche der Liste.

Die Funktionen, die sich speziell der Auswertung von Listenmodellen widmen, sind im vergangenen Jahrzehnt extrem angewachsen - und werden daher in den folgenden Abschnitten gesondert dargestellt.

Benutzerrollen

Wer den vorstehenden Text aufmerksam gelesen hat, wird die hier vorzustellenden drei Rollen schon identifiziert haben. Als Rolle soll hier eine Klassifizierung von Benutzeraktionen verstanden werden, die mit einem Tabellenkalkulationsmodell erledigt werden.

• Endanwender arbeiten mit einem "fertigen" Modell; sie ändern daran nicht, sondern füllen nur die definierten Eingabezellen aus. Sie müssen, wenn Sie ein solches Modell öffnen, schnell erkennen können, was dessen Aufgabe ist und die entsprechenden Ergebnisse erhalten, wenn Sie die erfordlichen Daten eingegeben haben. Endanweder sollten - weder absichtlich noch unabsichtlich - das Modell verändern können. Wenn Sie selbst ein früher erstelltes Modell wieder anwenden, dann sind Sie auch selbst in der Rolle des Endanwenders.

• Modellverwalter können zusätzlich aus die Systemparameter verändern und damit die Funktion des Modells beeinflussen - aber eben nur insoweit, als solche Änderungen bereits vorgedacht und durch entsprechende Eingaben in Konfigurationstabellen explizit gemacht sind. Ein Modellverwalter muss daher geschützte Tabellen entsperren können, um diese Systemparameter zu ändern. Will man die Funktion klar vom Modellersteller trennen, so müssen diese Konfigurationsdaten auf einen eigenes Tabellenblatt ausgelagert und zusammengefasst werden, damit dafür ein eigenes Kennwort vergeben werden kann.

• Modellersteller haben das gesamte Modell erstellt und können es auch in jeder Richtung wieder abändern. Sie haben auch die Entscheidungsgewalt, auf die Festlegung von Rechtebeschränkungen für Modellverwalter und Endanwender zu verzichten und damit auch jedem anderem die Rolle als Modellersteller zu ermöglichen

Nur zur Klarstellung: Diese Unterscheidung in drei Rollen ist keine Funktion, die Sie in irgendeinem Tabellenkalkulationsprogramm finden - es ist selbst ein Modell. Sie sollten sich klar werden, für welche Rolle Sie eine Lösung erarbeiten - und erst aufgrund dieser Entscheidung wird beurteilbar, ob Ihre Lösung als gut oder weniger gut anzusehen ist. Wenn Sie eine Lösung nur für sich selbst erstellen und diese auch selten benutzen werden, dann wird die Ausgestaltung der Rollen sehr rudimentär bleiben und sich wohl auf die des Modellerstellers beschränken. Soll Ihre Lösung dagegen auch anderen als Unterstützung dienen, dann müssen Sie sehr viel mehr Gedanken in die Rollenanforderungen investieren.

Literatur

Weiterführende Links

• Institut für Datenverarbeitung
• Johannes Kepler Universität
• MUSSS-Moodle

Zitiervorschlag

Höller in Pils, Informationsverarbeitung I 1.00, Tabellenkalkulationsmodelle#Überschrift (mussswiki.idv.edu/iv1)