Tabellenkalkulationsmodelle: Unterschied zwischen den Versionen

Aus IV1
Hh (Diskussion | Beiträge)
Die Seite wurde neu angelegt: „{{Kurzform|Tabellenkalkulationsprogramme können sowohl für Dokumentationsaufgaben wie auch für Modellierungsaufgaben eingesetzt werden; nur mit letzterem besch...“
 
K Textersetzung - „mussswiki.idv.edu“ durch „mussswiki.idb.edu“
 
(45 dazwischenliegende Versionen von 10 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
{{Kurzform|Tabellenkalkulationsprogramme können sowohl für Dokumentationsaufgaben wie auch für Modellierungsaufgaben eingesetzt werden; nur mit letzterem beschäftigt sich dieses Kapitel. Die unterschiedliche Ausrichtung der beiden Aufgabenkategorien sollen Ihnen bewusst werden.
<div class='noprint'><yambe:breadcrumb>Tabellenkalkulation|Tabellenkalkulation</yambe:breadcrumb></div>
Tabellenkalkulationsprogramme sind selbst die Implementierung eines Modells – und darauf ergeben sich Restriktionen, die Sie kennen müssen, um darauf Ihre eigenen Modelle aufbauen zu können. Schlussendlich werden S ie erfahren, wie Sie solche Funktionen einsetzen, um Modelle zweckmäßig für Analyseaufgaben aufzubauen. Die Beispiele werden am Open-Source Produkt OpenOffice demonstriert; die Unterschiede zum Marktführer Microsoft-Excel sind aber selten größer als zwischen unterschiedlichen Versionen von Excel. Wenn Sie also Excel schon kennen, was der Normalfall sein dürfte, so ist die Verwendung von OpenOffice eine willkommene Prüfung Ihrer Fähigkeit, vorhandenes Wissen auf zwar andere, aber ähnliche Umgebungen übertragen zu können – eine Fähigkeit, die immer wieder von Ihnen gefordert werden wird.}}
{{Kurzform|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.}}




Zeile 6: Zeile 6:




== (K)Ein Modell? ==
== Formularmodell ==


Es wurde eingangs behauptet, man könne Tabellenkalkulationsprogramme sowohl für Dokumentationsaufgaben wie auch für Modellierungsaufgaben verwenden. Wie kann man aber nun erkennen, um welchen Aufgabentyp es sich handelt - bzw. handeln soll?
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.  


Modell sind, so haben Sie aus Schauer <ref>Schauer, Reinbert, Betriebswirtschaftslehre, Grundlagen, 2., erw. Auflage, Wien 2009, S. 28</ref> in Erinnerung, "(stark) vereinfachte Abbilder der Realität, die entwickelt werden, um komplexe Zusammenhänge in den Betrieben wie in der Wirtschaft überschaubarer zu machen und auf wesentliche Elemente oder Eigenschaften zu reduzieren". Weiters wird dort in Erklärungsmodelle und Entscheidungsmodelle unterschieden und rein deskriptive Beschreibungsmodelle als Vorstufe zu Erklärungsmodellen dargestellt.
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.  


Mit dem in der Einleitung formulierten "Vorbehalt" verwenden wir das Beispiel einer Tätigkeitsaufzeichnung, wie Sie von Ihnen selbst stammen könnte. Sie sollen (rein deskriptiv) aufzeichnen, welcher Zeitaufwand für Sie bei der Absolvierung dieser Lehrveranstaltung entsteht und dabei zwischen den Lernphasen "Selbststudium", "Tutorium" und "Präsenz" unterscheiden und den Gesamtaufwand je Woche in einer Grafik darstellen. Diese Aufzeichnung stellt eine wesentliche Grundlage für die Entscheidung dar, ob die ECTS-Punktegewichtung mit den Inhalten in Einklang steht - und ist somit Bestandteil eines Entscheidungsmodells.
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:<br>


[[Datei:LernLogbuch.jpg]]


Wie können Sie nun beurteilen, ob die in Abb. x dargestellte Lösung eine geeignetes "Modell" darstellt? Manche Faktoren sind "von außen" - also schon von der Abbildung her erkennbar, andere jedoch nur "von innen" - also nur unter Beachtung der Eingabe in den jeweiligen Zellen, da ein feste Eingabe und ein berechnetes Ergebnis "von außen" nicht unterscheidbar sind.
[[Datei:Preiskalkulation gut schlecht.png]]<br>


* Der Zeitraum "von - bis" in einer Zelle bedeutet, dass das als Textfeld eingegeben wurde. Damit ist eine Berechung - etwa der Dauer - auf Basis dieser Eingabe zwar nicht unmöglich, aber doch so komplex, dass Sie nicht zu erwarten ist.
''Abb. 1: Preiskalkulation - Vergleich verschiedener Lösungen''
* Die getrennte Aufzeichung der Aktivitäten je Lernphase macht eine "modellhafte" Berechnung der Summe je Woche unmöglich
* Kontrollieren würde man dann noch, ob die Kalenderwoche fix eingetragen wurde oder ob das mit einer Formel berechnet wurde; der Wert hängt zweifellos vom Datum ab und wenn diese Beziehung nicht durch eine Formel abgebildet wird, dann ist ein wesentliches Merkmal des Modells nicht abgebildet.


Die Lösung ist Abb. 1 ist also ein typisches Beispiel, in dem das Tabellenkalkulationsprogramm fürs Dokumentieren eingesetzt wurde - dasselbe hätte man auch mit einem Textverarbeitungsprogramm erreichen können; selbst einfache Formeln kann man dort nämlich in Tabellen verwenden.
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 erstellen - und es 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.


== Wie sonst? ==
Auch wenn unser Beispiel so einfach wie möglich ist, sehen Sie daran die wesentlichen Kriterien für Formularmodelle:


Manche werden sich angesichts Abbildung 1 nun fragen, wie denn sonst man eine solche Aufgabe lösen sollte. Eine mögliche Lösung zeigt Abb. 2:
* Klarer Aufbau, der der Denklogik des Endanwenders folgt.
* Visuelle Signalisierung von Eingabezellen.
* Gültigkeitsprüfung von Eingaben, wenn nur bestimmte Wertebereiche zulässig sind.
* Schutz von Zellen vor unbeabsichtigter bzw. versehentlicher Eingabe.
* Auslagerung von Systemparametern abseits des Modells, mit sprechenden Namen, aber dynamisch in das Modell eingebaut.


[[Datei:LernLogbuch-Modell.jpg]]
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 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 Sie das schon selbst bei der Arbeit auf einem Notebook! Bevor Sie ein Modell als "fertig" ansehen, erstellen Sie stets ein 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.


Was sind nun die Vorzüge dieser Lösung? Von außen betrachtet ist wenig erkennbar - einige werden wohl sogar die erste Lösung "schöner" finden. Das wird wohl auch stimmen - denn grafische Gestaltung steht manchmal in Widerspruch zu zweckmäßiger Modellierung. Ein paar Indizien für sinnvolle Modellierung sind aber doch erkennbar:
== Listenmodell ==
* Manche Zellen sind kursiv, andere in Normaldruck und unterstrichen. Auf den zweiten Blick sollten Sie erkennen, dass die einen berechnet werden, die anderen Eingabedaten sind. Wenn Sie mit der Tabelle arbeiten, werden Sie feststellen, dass Sie mit der TAB-Taste automatisch nur auf jene Zellen kommen, die durch die Unterstreichung gekennzeichnet sind.
Ein Listenmodell haben Sie schon kennengelernt: Unser Beispiel in Abschnitt [[Analysieren_als_Entscheidungsvorbereitung#Wie_sonst.3F | Analysieren als Entscheidungsvorbereitung - Wie sonst?]] war ein Listenmodell.
* Die Zeiten von und bis sind in getrennten Spalten; es ist daher einfach möglich, die Stunden als Differenz zu berechnen.
* Die Phase ist nun als eigene Spalte ausgewiesen - das ermöglicht es einfach, durch die Anwendung des Befehls "Sortieren" auch eine Gruppierung nach Phase herzustellen.
* Die Summe je Kalenderwoche ist ebenfalls in einer eigenen Spalte ausgewiesen. Das deutet darauf hin, dass dieser Modell einfach erweiterbar sein kann, indem neue Zeilen leicht einfügbar ist. Mehr als die Option kann man von außen nicht erkennen, der Rest ist anhand der Formeln nur von innen prüfbar.
Wenn Sie eine Lehrveranstaltung aus Informationsverarbeitung besuchen, wird Ihnen im Tutorium auch die Tabelle zur Prüfung "von innen" zur Verfügung stehen. Dann können Sie auch die folgenden Modellmerkmale prüfen:
* Die Kalenderwoche wird automatisch berechnet; Sie können diese Zelle nicht ändern, weil diese Zelle gesperrt ist. Sie ist daher auch kursiv gekennzeichnet.
* Datum, von und bis sind Eingabezellen; sind sind durch entsprechend benannte Formate als nicht gesperrt definiert und zur visuellen Kennzeichnung für den User unterstrichen. (Vertiefungsthema Tabellen schützen)
* Stunden werden wiederum berechnet; ebenso die Summe je Kalenderwoche.
* Diese Summe enthält eine relativ einfache Formel, die in jeder Zeile berechnet wird, aber durch eine bedingte Formatierung nur in der jeweils letzten Zeile einer Kalenderwoche angezeigt wird. (Vertiefungthema Bedingte Formatierung)


Diese Tabelle stellt sicher, dass alle Beziehung zwischen den Elementen des Modells, die da wären,
Listenmodelle enthalten viele gleichartige Objekte, die in der Regel zeilenweise aufgebaut sind. Listenmodelle weisen daher eine gewisse Verwandtschaft zu jenen Daten auf, die typischerweise in Datenbanken gespeichert sind.
* Die Kalenderwoche ergibt sich aus dem Datum
* Die Stunden ergeben sich aus Beginn- und Endzeit
* Die Summe je Kalenderwoche ergibt sich aus den Stunden je Arbeitsphase in derselben Kalenderwoche
* Die Gesamtsumme ergibt sich aus der Stundensumme aller Tage.
automatisch richtig berechnet werden; ein versehentliche falsche Verknüpfung durch den User kann nicht vorkommen. Sie können nach Aufhebung des Tabellenschutzes auch Zeilen einfügen - die einzige Aktion, die ggf. erforderlich sein wird, ist das Sortieren der Tabelle. Eine Voraussetzung für das Funktionieren des Modells ist nämlich, dass die Daten nach dem Datum aufsteigend sortiert sind.


Diese Voraussetzung können Sie auch nicht "automatisch" beheben - wieso das so ist, erfahren Sie später im Abschnitt "Prozedural vs. Non-Prozedural".
Der Vorteil von Tabellenkalkulationsmodellen ist dabei, dass es flexiblere Möglichkeiten der Auswertung und Analyse der Daten gibt, als dies mit üblichen Datenbank-Abfragesprachen 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.


Wenn Ihnen noch Verbesserungsvorschläge für die dargestellte Lösung einfallen, dann haben Sie zweifellos recht - auch der Autor hatte solche. Wir wollen es für den Moment dennoch bei diesem Stand belassen und uns der Frage zuwenden, auf welchem Fundament man bei der Arbeit mit Tabellenkalkulationsprogrammen aufbaut und wieso man manche Probleme mit Tabellenkalkulationsmodellen nicht lösen kann.
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.


== Was hat Programmierung mit Tabellenkalkulation zu tun?==
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.


Die Antwort wird Sie möglicherweise überraschen: Die Erstellung von Tabellenkalkulationsmodellen ist eine Form der Programmierung. Grundprinzip der Programmierung ist es, Regeln zu formulieren, die aufgrund von gegebenen Eingabedaten neue Ergebnisse erzeugen. Es ist eine sehr spezialisierte und benutzernahe Form von Programmierung, die Sie mit Hilfe von Tabellenkalkulationsprogramme betreiben - aber die Grundprinzipien sind dieselben. Vieles wird Ihnen bei Tabellenkalkulationsprogrammen "abgenommen" - aber für die Gestaltung komplexerer Modelle, insb. bei Grenzfällen bzw. bei der Fehlersuche, sind die allgemeinen Prinzipien für die Beurteilung der Softwarequalität auch in Zusammenhang mit Tabellenkalkulationsmodellen von Belang.
Auch bei Listenmodellen kann die Aktivierung des Zellschutzes sowie die Gültigkeitsprüfung von Eingabewerten zweckmäßig sein. Ein besonders interessantes Feature im 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.


Sie sollten daher Modelle so entwickeln, dass andere (und auch Sie selbst nach längerer Pause) den Sinn des Modells rasch erkennen und auch nachprüfen können. Es sollte gleichzeitig auf neue Anforderungen anpassbar sein, was einen klar strukturierten Aufbau voraussetzt. Es sollte gleichzeitig die Daten in einer Form bereitstellen, die auch eine anschließende Weiterverarbeitung sicherstellt. Das erfordert ein Grundverständnis über die folgenden Programmierkonzepte:
Vielfach werden bei Listenmodellen den eingegebenen bzw. aus Datenbanken importieren Daten noch zusätzliche Spalten durch Berechnungsvorgä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.


=== Variable ===
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.
Allen Programmiersprachen ist gemeinsam, dass Sie Variable verwenden, um wechselnde Werte, mit denen im Programm gearbeitet wird, aufzunehmen. Immer sind diesen Variablen Speicheradressen zugeordnet - bei der Tabellenkalkulation auch. Die "Speicheradressen" der Variablen sind hier die Zellreferenzen: Von A1 bis AS65535 zum Beispiel. Bei der Programmierung verwendet man üblicherweise "sprechende" Bezeichnungen. "Bruttobetrag - MWSt" liefert wesentlich mehr Bedeutung ("Semantik") als "B1-B2". Auch wenn es selten verwendet wird, bieten auch Tabellenkalkulationsprogramme die erstgenannte Möglichkeit: Man kann für Zellen oder Zellbereiche Namen vergeben und diese dann statt der Zelladressen verwenden. Namen werden dabei standardmäßig als absolute Adressen definiert.
Die Verwendung von Namen ist etwas umständlich; man wird daher nicht in jeder Formel Namen anwenden. Sehr zu empfehlen ist dies jedoch dort, wo eine Verweis auf weiter entfernte Zellen erfolgt, die außerhalb des sichtbaren Umfelds liegen und deren Bedeutung daher nicht "auf einen Blick" klar wird.  


=== Datentypen ===
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.
Programmiersprachen weisen meist ein sehr rigides Konzept an Datentypen auf; man muss vor jeder Verwendung einer Variablen angeben, welchem Datentyp sie zugeordnet ist. Der Datentyp definiert, welche Symbolkombinationen eine Variablen enthalten kann und welche Operationen auf diese Variable zugelassen sind. Die vorherige Typfestlegung ermöglichst es den Übersetzungsprogrammen (Compiler), schon vor der Laufzeit des Programms bestimmte Fehler zu erkennen.
Eine Typfestlegung in diesem Sinne ist Ihnen bei Tabellenkalkationsprogrammen noch nie untergekommen - und dennoch gibt es Datentypen auch hier. Ihnen ist sicher schon aufgefallen, dass Eingaben manchmal linksbündig, manchmal rechtsbündig angeordnet werden. Das ist eine Konsequenz der Zuordnung des Datentyps. Zahlen werden rechtsbündig, Texte werden linksbündig dargestellt - wobei das natürlich durch den User verändert werden kann.
Normalerweise erfolgt die Zuordnung des Datentyps implizit - d. h. dass anhand der eingegebenen Zeichen das Programm selbständig den passendsten Datentyp zuordnet.
* Die Matrikelnummer 0755345 wird daher als Zahl erkannt und typischerweise ohne führende 0 dargestellt. Das die Matrikelnummer aber immer siebenstellig sein muss, wäre hier der Datentyp "Text" zu wählen. Auch das können Sie erreichen, indem Sie das "Erkennungszeichen" ' für den Datentyp Text eingeben. Die Zahl wird dann als Datentyp Text zugeordnet und mit führender Null (rechtsbündig) in der Zelle angezeigt.
* Wenn Sie die Artikelnummer "2/2/4" in eine Zelle eingeben, dann wird das ebenfalls nicht als Text erkannt, sondern implizit dem Datentyp "Datum" zugeordnet.
* Der 1. 1. 20000 dagegen wird möglicherweise nicht als Datum erkannt werden, weil der Datumsbereich zB in Open Office im Jahr 9999 endet. Das wird zwar in aller Regel als Planungshorizont ausreichen - kann aber bei Tippfehlern durchaus unerwartete Konsequenzen haben.
Konsequenzen hat die Zuordnung von Datentypen insbesondere bei Formeln, die Zellen unterschiedlicher Datentypen verknüpfen. Hier unterscheiden sich teilweise die Tabellenkalkulationsprogramme. Alle konvertieren Datentypen, sofern das inhaltlich eindeutig möglich ist (zB Verkettung von Text und Zahl). Wenn das nicht möglich ist, ignorieren manche Programme die nicht konvertierbaren Werte einfach - andere geben einen Fehlerwert aus. Beides kann je nach Situation nützlich sein. Zu wissen, was das eigene Programm macht, ist allerdings bei der Fehlersuche sehr nützlich!


=== Prozedural vs. Non-Prozedural ===
== Benutzerrollen ==
Die meisten Programmiersprachen arbeiten "prozedural", d. h. dass der Weg zur Lösung des Problems Schritt für Schritt in einer formalen Sprache definiert werden muss. Das ist bei Tabellenkalkulation (und auch in SQL) anders: Bei diesen Werkzeugen, die dann als "Non-prozedural" bezeichnet werden, sind die Lösungswege bereits "vorgedacht" und nur mehr durch die eingegebenen Daten "modifizierbar". Solche non-prozeduralen Tools sind daher auch auf eine bestimmte Kategorie von Problemstellungen beschränkt und nicht wie prozedurale Programmiersprachen universell einsetzbar.
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 nichts, 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.  


Wenn Sie an Beispiel 2 zurückdenken: Sie würden sich vielleicht wünschen, dass die Tabelle sich automatisch aufsteigend nach Datum sortiert, falls einmal ein Datum außerhalb der Reihenfolge eingegeben wird. Eine solche Forderung ist mit dem Prinzip der "Non-Prozeduralität" nicht vereinbar - solange es nicht durch eine entsprechende Funktion im Programm "vorgedacht" ist. Vieles, was heute etwa durch die bedingte Formatierung möglich ist, hätte man vor einigen Jahren noch als Beispiel für das Erfordernis prozeduraler Programmierung verwendet.  
* Modellverwalter können zusätzlich auch 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 ein eigenes Tabellenblatt ausgelagert und zusammengefasst werden, damit dafür ein eigenes Kennwort vergeben werden kann.


Auch wenn diese Entwicklung sicher weitergehen wird, werden immer Aufgaben verbleiben, die nur durch prozedurale Programmierung lösbar sind. Wenn ein Großteil der Aufgabe aber durch Tabellenkalkulation lösbar ist, wäre es sinnlos, das alles prozedural "nachzuprogrammieren". Jedes moderne Tabellenkalkulationswerkzeug bietet daher als Zusatzfeature auch die Erweiterung von prozeduralen Lösungen im Form von Makros an. In der einfachsten Version können Sie ein Makro erzeugen, indem Sie eine Aktion manuell ausführen und diesen Vorgang aufzeichnen. Sie erzeugen damit den Sourcecode eines Makros, das Sie weiter bearbeiten - wenn Sie es können. Im Rahmen dieses Kurses werden Sie das nicht lernen.
* 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 anderen 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 ==


=== Quellen ===
<references/>
=== Weiterführende Links ===
* [http://www.idv.edu Institut für Datenverarbeitung]
* [http://www.jku.at Johannes Kepler Universität]
* [http://musss.jku.at/moodle MUSSS-Moodle]


== Zitiervorschlag ==
== Zitiervorschlag ==
''Höller'' in ''Pils'', Informationsverarbeitung I 1.00, Analysieren als Entscheidungsvorbereitung#Überschrift (mussswiki.idv.edu/iv1)
''Höller'' in ''Höller'', Informationsverarbeitung I, Tabellenkalkulationsmodelle (mussswiki.idb.edu/iv1)

Aktuelle Version vom 1. Oktober 2018, 14:10 Uhr

<yambe:breadcrumb>Tabellenkalkulation|Tabellenkalkulation</yambe:breadcrumb>
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:



Abb. 1: Preiskalkulation - Vergleich verschiedener Lösungen

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 erstellen - und es 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 Formularmodelle:

  • Klarer Aufbau, der der Denklogik des Endanwenders folgt.
  • Visuelle Signalisierung von Eingabezellen.
  • Gültigkeitsprüfung von Eingaben, wenn nur bestimmte Wertebereiche zulässig sind.
  • 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 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 Sie das schon selbst bei der Arbeit auf einem Notebook! Bevor Sie ein Modell als "fertig" ansehen, erstellen Sie stets ein 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 in der Regel 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 Datenbank-Abfragesprachen 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 im 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 Berechnungsvorgä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 nichts, 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 auch 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 ein 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 anderen 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.


Zitiervorschlag

Höller in Höller, Informationsverarbeitung I, Tabellenkalkulationsmodelle (mussswiki.idb.edu/iv1)