Digitale Datenverwaltung im Rahmen arbeitswissenschaftlicher
Werbung
Digitale Datenverwaltung im Rahmen arbeitswissenschaftlicher Untersuchungen Seminararbeit im WS 2011/2012 von Carina Huchler Betreuer: Prof. Dr. rer. nat. Gerhard Dikta Dipl.-Inform. Sinem Kuz Inhalt 1 2 3 Einleitung ................................................................................................................................. 3 1.1 Motivation ......................................................................................................................... 3 1.2 Aufbau der Seminararbeit .................................................................................................. 4 Vergleich von Möglichkeiten der digitalen Datenverwaltung ............................................. 5 2.1 Dateibasierte Datenverwaltung ...................................................................................... 5 2.2 Datenbanken .................................................................................................................... 6 2.2.1 Relationale Datenbanken ......................................................................................... 7 2.2.2 Objektorientierte Datenbanken............................................................................... 9 2.2.3 Objekt-relationale Datenbanken ........................................................................... 10 Darstellung der zu verwaltenden Daten.............................................................................. 13 3.1 3.1.1 Die Antwort durch Selektion ................................................................................. 13 3.1.2 Die schriftliche Antwort ......................................................................................... 14 3.1.3 Strahl ........................................................................................................................ 14 3.1.4 Zahlenstrahl ............................................................................................................ 14 3.1.5 Fragen mit Zuordnung ........................................................................................... 14 3.1.6 Fragen mit Bildern .................................................................................................. 15 3.2 4 Fragetypen ...................................................................................................................... 13 Sonstiges ......................................................................................................................... 15 3.2.1 Bilder ....................................................................................................................... 15 3.2.2 Mengenwertige Daten ............................................................................................ 15 3.2.3 Andere Informationen ............................................................................................ 16 Auswahl des Datenmodells................................................................................................... 17 4.1 Erweiterbarkeit .............................................................................................................. 17 4.2 Flexibilität ....................................................................................................................... 17 1 5 4.3 Struktur ........................................................................................................................... 17 4.4 Modellierbarkeit ............................................................................................................ 18 4.5 Datensicherheit .............................................................................................................. 18 4.6 Standardisierung ............................................................................................................ 18 4.7 Programmiersprache ..................................................................................................... 19 4.8 Auswahl des Datenmodells anhand der Kriterien ...................................................... 19 Aufbau der Datenbank .......................................................................................................... 20 5.1 Grundstruktur ................................................................................................................ 20 5.2 Fragen-Katalog ............................................................................................................... 20 5.3 Probanden-Daten ........................................................................................................... 21 5.4 Fragebögen ..................................................................................................................... 21 6 Ausblick auf die Bachelorarbeit ........................................................................................... 23 7 Fazit ........................................................................................................................................ 24 Literaturverzeichnis ........................................................................................................................ 25 A Anhang .................................................................................................................................... 25 Eidesstattliche Erklärung................................................................................................................ 26 2 1 Einleitung Das Ziel der Seminararbeit ist die Auswahl und eine erste Modellierung eines Datenmodells für die Abspeicherung von Fragebögen. Dieses Datenmodell wird benötigt, um Fragebögen abzuspeichern, die im Rahmen arbeitswissenschaftlicher Untersuchungen durchgeführt werden. Dabei sollen alle relevanten Bereiche in dem Datenmodell abgespeichert werden. Dazu gehören die Fragen, die Konstellation der Fragen, wie sie im Fragebogen gestellt werden und die Ergebnisse, die durch Beantwortung der Probanden auf die Fragen entstehen. Warum dies nötig ist, wird nun in der Motivation erklärt. 1.1 Motivation Am Lehrstuhl und Institut für Arbeitswissenschaft der RWTH Aachen werden häufig empirische Probandenstudien hinsichtlich der Erfüllung ergonomischer Standards und Kriterien durchgeführt. Dabei werden in der Regel alle notwendigen Informationen mittels papierbasierter Fragebögen ermittelt. Diese Fragebögen erfassen nicht nur demografische Daten wie Alter oder Geschlecht, sondern können auch Rückschlüsse über den körperlichen oder geistigen Zustand des Probanden liefern. Des Weiteren können mittels dieser Fragebögen auch Informationen ermittelt werden, die Aufschluss über das logische Verständnis oder das räumliche Vorstellungsvermögen des Probanden geben. Um die Antworten entsprechend präzise erfassen zu können, werden verschiedene Antwortmöglichkeiten benutzt, wie das Setzen eines Kreuzes auf einem Zahlenstrahl. Wie bereits erwähnt, müssen solche Fragebögen manuell von der entsprechenden Person ausgefüllt werden. Aus diesem Grund kann es vorkommen, dass die Informationen nicht mehr eindeutig identifizierbar sind. Dies führt dazu, dass der Inhalt nicht mehr ausgewertet werden kann. Deshalb soll ein System entwickelt werden, wodurch diese Informationen, die bisher papierbasiert ermittelt worden waren, digital verwaltet werden können. Dadurch entstehen viele Vorteile. Momentan müssen die ausgefüllten Fragebögen manuell digitalisiert werden. Sollten die Fragebögen jedoch von Anfang an auf dem Computer eingegeben werden, würde dieser Schritt entfallen, wodurch Zeit gespart wird. Nachdem die Fragebögen eingegeben wurden, müssen sie dennoch für eine bestimmte Zeit aufbewahrt werden. Durch die Digitalisierung wäre das nicht mehr notwendig, da die Daten auf dem Computer gesichert wären. 3 Deshalb sollen im Rahmen dieser Arbeit die Möglichkeiten zur digitalen Datenverwaltung verglichen und bewertet werden, um das passende Datenmodell für ergonomische Untersuchungen auszuwählen. 1.2 Aufbau der Seminararbeit Die vorliegende Arbeit lässt sich in unterschiedliche Bereiche aufteilen. Zuerst sollen die Möglichkeiten zur digitalen Datenverwaltung verglichen werden. Hierzu werden vier Datenmodelle vorgestellt und ihre Vor- und Nachteile benannt. Danach soll Einblick in die zu verwaltenden Daten gegeben werden. Dazu soll zuerst auf die verschiedenen Fragemöglichkeiten eingegangen werden. Wenn diese Thematik abgearbeitet ist, soll auch auf die anderen Anforderungen Bezug genommen werden, die an die digitale Datenverwaltung gestellt werden. Im nächsten Abschnitt wird dann anhand von Kriterien, die sich aus den vorherigen Ergebnissen entwickelt haben, ein Datenmodell ausgewählt. Mit Hilfe dieses Datenmodelles und der vorliegenden Anforderungen wird zum Schluss der Aufbau des Modelles beschrieben. 4 2 Vergleich von Möglichkeiten der digitalen Datenverwaltung Dieses Kapitel beschreibt die verschiedenen Möglichkeiten der digitalen Datenverwaltung, mit dem Ziel diese im Anschluss nach vorgegebenen Kriterien zu bewerten. 2.1 Dateibasierte Datenverwaltung Das Modell der dateibasierten Datenverwaltung ist eines der bekanntesten Datenmodelle heutzutage. Diese Art der Datenverwaltung hat keine vorgegebene Struktur, sondern wird von demjenigen, der das Datenmodell entwickelt, bestimmt. Dies führt zu einer festen Beziehung zwischen Datei und Anwendung, wobei eine n:m-Beziehung zwischen Datei und Anwendung entstehen kann. Eine solche n:m-Beziehung funktioniert, indem es n Anwendungen gibt, die mit Hilfe von Java entwickelt worden sind. Jede dieser Anwendungen kann auf bis zu m Dateien zugreifen, wobei es möglich ist, dass mehrere Anwendungen die gleiche Datei benutzen. Als Dateityp kommt zum Beispiel eine Textdatei in Frage. Es gibt mehrere Arten eine dateibasierte Datenverwaltung aufzubauen. Eine Methode ist, eine Datei zeilenweise aufzubauen und so eine Art Tabelle zu generieren, wobei die einzelnen Werte durch ein Trennzeichen voneinander abgegrenzt werden. Um Daten auszulesen, zu entfernen oder neu zu erstellen, muss die Datei vollständig eingelesen und in der Anwendung verarbeitet werden. Vor- und Nachteile Da eine feste Beziehung zwischen Datei und Anwendung besteht, ist eine Erweiterbarkeit nur bedingt möglich. Man kann die Datenstruktur zwar um beliebige Eigenschaften erweitern, aber dies kann in der Anwendung selbst zu Problemen führen. Die feste Struktur zwischen Datei und Anwendung sorgt dafür, dass bei Änderung der Datenstruktur sowohl die Datei als auch die Anwendung geändert werden muss. Dies macht die dateibasierte Datenverwaltung statisch, da bei Änderung der Daten ein großer Mehraufwand entsteht. Es treten vor allem Probleme im Bereich der Datensicherheit auf, da die Daten meistens unverschlüsselt abgespeichert werden und die Dateien deshalb mit einem Texteditor geöffnet werden können. Sollten Datei und Anwendung zur Verfügung stehen, stellt es kein Problem dar, die Daten zu manipulieren und auch auszulesen. Wenn Datensicherheit gewährleistet werden soll, muss der Entwickler die Daten selber vor unbefugtem Zugriff absichern. Diese Absicherung kann man durchführen, indem man die Daten über ein Passwort schützt oder sie verschlüsselt. 5 Da die Datei nur aus Zahlen und Buchstaben besteht und alles andere selbst implementiert werden muss, sind auch keine komplexen Abfragen möglich. Für jeden Zugriff auf die Daten muss eine eigene Methode geschrieben werden. Das kann dazu führen, dass die Anwendungen unübersichtlich werden und es so schwer ist, die Software nachzuvollziehen. Manchmal speichern mehrere Anwendungen gleiche Daten ab. Normalerweise besteht eine 1:1 Beziehung zwischen Daten und Anwendungen. Dies führt zu Datenredundanz, da Daten so mehrfach abgespeichert werden. Ein weiteres Problem kann die Inkonsistenz der Daten sein, das heißt, dass unterschiedliche Anwendungen andere Informationen haben, die eigentlich gleich sein sollten. Um dies zu verhindern, müssten alle Anwendungen die Struktur von allen benutzten Dateien kennen und diese anpassen. Um dieses Problem zu lösen, könnte die Anwendung so weit verändert werden, dass alle Anwendungen auf die gleichen Daten zugreifen. Dann muss jedoch ein einheitliches Schema für die Daten gewählt werden. Dies führt aber dazu, dass bei Änderung der Datenstruktur diese Änderung für alle Programme und Dateien übernommen werden muss. Ein weiterer wichtiger Punkt ist, dass bereits am Anfang überlegt werden muss, ob die Daten einmal oder immer wieder neu geladen werden. Jede dieser beiden Varianten hat Vor- und Nachteile. Wenn die Daten nur einmal geladen werden, werden Festplattenzugriffe gespart, die in der Regel sehr langsam sind. Werden die Daten jedoch immer wieder neu geladen, würde die Daten nach jedem Zugriff abgespeichert werden und so ein Verlust der Daten verhindert werden. Eine gute Kombination wäre es zum Beispiel die Daten einmal zu laden und dem Benutzer die Möglichkeit geben zu entscheiden, wann abgespeichert werden soll. Ein weiteres Problem ist es, dass in der Dateibasierten Datenverwaltung im Prinzip kein Mehrbenutzerbetrieb möglich ist. Dies kommt daher, dass eine Datei nicht von zwei Personen gleichzeitig bearbeitet werden kann. Der große Vorteil der Dateibasierten Datenverwaltung ist, dass die Dateistruktur nach Belieben aufgebaut werden kann und so der Problemstellung angepasst wird. Dies kann natürlich auch ein Nachteil sein, wenn das Programm zu komplex gestaltet wird, oder wenn eine andere Person sich in die Software einarbeiten möchte. 2.2 Datenbanken Eine Datenbank besteht aus einer Menge von Daten. Diese Daten sollen einen Ausschnitt der realen Welt darstellen. Dazu werden sie elektronisch verwaltet und gespeichert. Außerdem sind 6 diese Daten logisch miteinander verknüpft und haben damit eine implizite Bedeutung. Die Grundlage für diese Bedeutung bilden die Zielgruppen, für welche die Datenbank entwickelt wurde. Jede Datenbank unterliegt nämlich einem bestimmten Zweck, der durch die Zielgruppe bestimmt wird. Dabei soll es eventuell möglich sein, dass die Zielgruppe Informationen auslesen und neue Informationen hinzufügen kann. Es kann jedoch zwischen verschiedenen Zielgruppen unterschieden werden, die alle unterschiedliche Rechte haben können. (Elmasri & Navathe, 2005, S. 18) 2.2.1 Relationale Datenbanken Die relationale Datenbank ist eine oft verwendete Datenbank. Das relationale Modell wurde 1970 von Ted Codd entwickelt und ist inzwischen der Standard für Datenbanken. (Elmasri & Navathe, 2005, S. 133) Die Datenbank selbst besteht aus einer Sammlung von Relationen, die wie eine Anzahl von Tabellen aufgebaut sind. Jede dieser Tabelle ist über eine nicht festgelegte Anzahl von Zeilen aufgebaut. Eine Zeile wird in der Terminologie der relationalen Datenbank Tupel genannt. Jedes Tupel besteht aus mehreren Eigenschaftswerten. Jedem Eigenschaftswert ist ein Attribut zugewiesen. Diese Attribute sind vergleichbar mit Spaltenüberschriften in einer Tabelle. Eine solche Spalte gibt damit einen Wertebereich oder auch Domain an. (Elmasri & Navathe, 2005, S. 133-134) Jeder Wert einer Domain ist atomar. Das bedeutet, dass dieser Wert in keine anderen Eigenschaften unterteilt werden kann. (Elmasri & Navathe, 2005, S. 135) Bei relationalen Datenbanken kann im formalen Bereich zwischen zwei verschiedenen Sprachen unterschieden werden. Diese Sprachen basieren entweder auf der Relationalen Algebra oder auf dem Relationenkalkül. Bei der relationalen Algebra handelt es sich um eine Sprache, die es ermöglicht, einen Abarbeitungsplan für die Anfrage zu realisieren. Das Relationenkalkül fragt bei einer Abfrage Kriterien ab, welche zur Selektion der Daten dienen. Damit wird aber kein Abarbeitungsplan wie bei der relationalen Algebra erstellt. (Kemper & Eickler, 2001, S. 82) Zusätzlich gibt es bereits eine standardisierte Abfragesprache, die sich SQL nennt. Sie wurde von ANSI und ISO standardisiert und basiert auf der Relationalen Algebra. SQL dient dazu, Daten zu verändern einzufügen oder zu löschen. (Elmasri & Navathe, 2005, S. 181-182) Vor- und Nachteile Ein Vorteil der relationalen Datenbanken ist, dass es bereits eine standardisierte Programmierspiersprache für dieses Datenmodell gibt. Die Programmiersprache ermöglicht es 7 dem Benutzer Anfragen zu stellen. Durch diese Anfragen können Daten ausgelesen, hinzufügt, geändert und gelöscht werden. Durch Anfragen können neue Tabellen erstellt, alte Tabellen gelöscht und bestehende Tabellen geändert werden. Ein weiterer großer Vorteil ist die Grundlage der formalen Sprache, die in der relationalen Datenbank benutzt wird. Die relationale Algebra bietet zum Beispiel viele Methoden, um verschiedenste Arten der Abfragen zu gestalten. Dazu gehören die Selektion, die Projektion, die Vereinigung, die Mengendifferenz, das Kartesische Produkt und die Möglichkeit, Attribute und Relationen umzubenennen. Die Selektion ermöglicht Abfragen, die ein bestimmtes Attribut der Datenbank mit einem Wert vergleichen. Sollte der Vergleich eine Übereinstimmung ergeben, wird das Tupel zurückgegeben. Dies passiert natürlich für alle Tupel, die mit der Abfrage übereinstimmen. Ein weiterer Vorteil der relationalen Algebra ist die Vereinigung. Durch die Benutzung der Vereinigung in einer Abfrage, können zwei Tupel aus zwei Tabellen vereinigt werden. (Kemper & Eickler, 2001, S. 82-90) Liegen zwei Tabellen vor und beide beinhalten das Attribut Personalnummer, werden durch die Abfrage, ob die beiden Personalnummern gleich sind, die Tabellen zusammengeschlossen. Das Resultat dieser Abfrage wäre dann ein Zusammenschluss der beiden Tabellen, wobei eine Tabelle um die Attribute der anderen Tabelle erweitert wird. Das Relationenkalkül bietet ähnliche Vorteile, da jede Abfrage, die in der relationalen Algebra möglich ist, auch im Relationenkalkül ausdrückbar ist. Da die Abfragen so vielseitig gestalten werden können, bietet die relationale Datenbank eine gute Grundlage für die Gestaltung und Präzision der Abfragen. (Kemper & Eickler, 2001, S. 93) Es gibt außerdem die Möglichkeit einem Wertebereich einen Namen zuzuweisen. Dies kann sehr nützlich sein, denn je eindeutiger der Name gewählt wurde, desto intuitiver ist die Datenbank benutzbar. Diese Erweiterung ermöglicht es, auch komplexere Abfragen zu gestalten. Dies ist ein großer Vorteil, da so spezifizierte Daten einfach ausgelesen werden können. Wird zum Beispiel mit SQL auf eine Datenbank zugegriffen, existieren dazu vorgefertigte Algorithmen. Dies erleichtert die Abfragen von relationalen Datenbanken, da nicht zusätzlich ein Algorithmus geschrieben werden muss, der diese Abfragen für den Benutzer übernimmt. Ein weiterer wichtiger Bestandteil jeder Tabelle ist ein Attribut, welches die Eigenschaften eines Primary Key hat. Jeder Wert, der diesem Attribut zugewiesen wird, kann pro Tabelle maximal einmal vorkommen. Das macht jede Zeile in einer Tabelle eindeutig identifizierbar und ermöglicht Beziehungen unter den verschiedenen Tabellen einer Datenbank. Dies geschieht, 8 indem ein anderes Attribut in einer anderen Tabelle den gleichen Wert, wie der Primary Key hat. Für mehr Übersichtlichkeit wird häufig die gleiche Bezeichnung für den Primary Key und das Attribut der anderen Tabelle gewählt. Ein weiterer Vorteil der relationalen Datenbank ist, dass der Wertebereich eingegrenzt werden kann. So können unerwünschte Eingaben von Anfang an vermieden werden. Es wird dadurch eine Hilfestellung für die Überprüfung der Dateneingabe gegeben. (Elmasri & Navathe, 2005, S. 135) Objektorientierte Programmierung ist nicht möglich. Somit kann in relationalen Datenbanken zum Beispiel keine Vererbung durchgeführt werden, was ein schnelleres Anlegen ähnlicher Objekte ermöglichen würde. Für eine bessere Verdeutlichung wird nun ein Beispiel aus der Vererbung, wie sie in Java funktioniert, gegeben. Das Grundprinzip des Verfahrens ist immer das gleiche. Die Grundlage für die Vererbung bildet eine Klasse, die sich Schüler nennt. In dieser Klasse wurden die Variablen Name, Geburtstag und Schuljahr bereits angelegt. Außerdem besitzt die Klasse noch eine Methode, die das exakte Alter des Schülers berechnet. Diese Klasse wird an mehrere andere Klassen vererbt. Eine davon nennt sich „Ehemaliger“. Durch diese Klasse kann sowohl auf die Variablen als auch auf die Methoden der Klasse Schüler zugegriffen werden. Außerdem gibt es Zugang zu dem Abschlussjahr und dem endgültigen Notendurchschnitt des Abschlusses. Vererbung sorgt nicht nur dafür, dass Attribute und Methoden nicht in jeder Klasse erneut implementieren werden müssen, sondern auch dafür, dass die Klassen eine ähnliche Struktur haben. Somit sind sie übersichtlicher, da ein Teil von ihnen gleich ist und so bereits eine einheitliche Benennung von Variablen und Methoden vorliegt. 2.2.2 Objektorientierte Datenbanken Im Objektorientierten Datenbankmodell wird jedes Element, das abgebildet werden soll, durch ein Objekt dargestellt. Dabei können die Objekte auch eigene Methoden beinhalten. Diese Objekte haben immer ein Verhalten. Dieses Verhalten kann durch die Methoden, die jedes Objekt hat, geändert werden. Zusätzlich hat jedes Objekt einen Zustand, der durch die Werte der einzelnen Attribute bestimmt wird. Darüber hinaus kann jedes Objekt Beziehungen zu anderen Objekten haben. Damit ein Objekt eindeutig identifizierbar ist, besitzt jedes Objekt einen Bezeichner. (Kemper & Eickler, 2001, S. 357-358) Es wurde sogar ein Standard zusammengefügt, der sich Object Database Management Group– Standard (ODMG-Standard) nennt. Das Ziel dieses Standards ist es, das Modell in bereits 9 existierende Sprache einzubinden, was bis jetzt für C++ und Smalltalk geschehen ist. Die Anfragesprache, die durch die Einbindung entstanden ist, nennt sich OQL, was für Object Query Language steht. (Kemper & Eickler, 2001, S. 358) Vor- und Nachteile Da die Objekte durch Methoden manipuliert werden können, ist dies ein Vorteil gegenüber anderen Datenbankmodellen, die diese Fähigkeit nicht haben. Dies ermöglicht Objekte zu manipulieren, ohne dafür außerhalb der Objekte eine Methode zur Verfügung zu stellen. Ein weiterer Vorteil ist, dass die Daten über ihren Bezeichner eindeutig identifizierbar sind und so von anderen Objekten unterschieden werden können. Das ist deshalb vorteilhaft, weil die Objekte so einzigartig sind und somit nicht zweimal existieren können. (Kemper & Eickler, 2001, S. 357) Ein Nachteil ist, dass sich der ODMG-Standard (Object Database Management Group) noch nicht so durchgesetzt hat, wie der SQL-Standard der relationalen Datenbank. (Kemper & Eickler, 2001, S. 358) 2.2.3 Objekt-relationale Datenbanken Die Objekt-relationale Datenbank ist eine Erweiterung der relationalen Datenbank. Die Erweiterung gegenüber der relationalen Datenbank umfasst zum einen mehrere neue Datentypen, zum anderen die Einführung von Vererbung und eigene erstellte Objekte. Diese Objekte können sowohl Variablen als auch Methoden besitzen. Da es sich hierbei um eine Erweiterung handelt, ist sie bereits in manchen relationalen Datenbanken, wie zum Beispiel bei Oracle, fest implementiert und bildet somit kein komplett neues Datenmodell. Das Hauptziel der Objektrelationalen Datenbanken ist es, die Nachteile der relationalen Datenbank zu verbessern. (Kemper & Eickler, 2001, S. 391-392) Diese Erweiterung ist der SQL:1999 Standard. Er soll dafür Sorge tragen, dass es ein standardisiertes Objekt-relationales Datenmodell gibt, wobei auch die Programmiersprache mit eingeschlossen ist. (Kemper & Eickler, 2001, S. 392) Vor- und Nachteile Diese Datentypen umfassen zum Beispiel „Large Objects“ kurz „LOBs“. „LOBs“ ermöglichen die Speicherung von Daten, die einige Gigabytes groß sein können. So ist es zum Beispiel 10 möglich, Multimedia Objekte abzuspeichern. Die Abspeicherung von großen Objekten könnte beispielsweise zur Speicherung von Videos genutzt werden. (Kemper & Eickler, 2001, S. 391) Die neuen Datentypen umfassen auch Distinct Types. Sie ermöglichen es, benutzerdefinierte Datentypen zu erstellen. Diese Distinct Types müssen aus bereits vorhandenen Datentypen ableitbar sein und können einen vorhandenen Datentypen um Regeln erweitern. (Kemper & Eickler, 2001, S. 394) Es können aber auch komplette Objekte erstellt werden. Der größte Unterschied zwischen einer Tabelle in einer Objekt-relationalen Datenbank und einem Objekt ist, dass das Objekt vererbt wird und Funktionen für das Objekt deklariert werden können. Der Vorteil der Vererbung wurde bereits in Kapitel 2.2.1 erläutert. (Kemper & Eickler, 2001, S. 392) Ein weiterer Vorteil entsteht dadurch, dass Funktionen direkt auf den Objekten implementiert werden können. Diese Funktionen können bis zu einem gewissen Grad in SQL implementiert werden. Sollte die Funktion jedoch zu komplex sein, gibt es die Möglichkeit, die Operation über eine Schnittstelle, wie zum Beispiel Java, einzufügen. Der Vorteil besteht darin, dass bei Entwicklung einer Schnittstelle zu einem Programm nicht zusätzlich diese Funktionen implementiert werden müssen. So kann alles kompakt auf der Datenbank abgespeichert und durchgeführt werden. (Kemper & Eickler, 2001, S. 392) Es wurde auch eine Möglichkeit implementiert, um mengenwertige Attribute zu erstellen. Das heißt, dass einem Attribut in einem Tupel mehrere Werte zugewiesen werden können. Die Werte können alle separat voneinander aufgerufen werden. Das Attribut funktioniert also analog zu einem Array. Zusätzlich ist es möglich einem Attribut eine Relation bzw. Tabelle zuzuweisen. Liegt zum Beispiel eine Tabelle namens „Familientag“ vor, die den Familiennamen und den Vornamen eines jeden Elternteils beinhaltet, dann soll es zusätzlich noch möglich sein, eine beliebige Anzahl an Kindern einzufügen. Dies soll durch ein Attribut namens „Kinder“ durchgeführt werden. Dieses Attribut verweist im Objekt-relationalen Datenmodell auf eine Relation. Diese Relation hat zwei Attribute, die sich „Name“ und „Alter“ nennen. Bei relationalen Datenbanken wäre hier mit Schlüsseln gearbeitet worden, die so eine Verknüpfung zwischen Tupeln aus unterschiedlichen Tabellen gemacht hätten. Diese Erweiterung sorgt jedoch dafür, dass alle Informationen in einer Tabelle kompakt abgespeichert werden können. Im Konzept der relationalen Datenbanken hätte es zusätzlich eine Tabelle Kinder gegeben, in welcher alle Kinder aufgeführt gewesen wären. Dabei wäre nur über einen Schlüssel unterschieden worden, welches Kind zu welcher Familie gehört. Hätte die Familie ausgelesen 11 werden sollen, hätte man dies zum Beispiel über eine Vereinigung machen können, indem die beiden Tabellen über diesen Schlüssel miteinander verbunden worden wären. Die Abfrage hätte dann für jede Familie so viele Rückgaben gegeben, wie es Kinder gibt. In diesem Modell gibt es jedoch nur eine Rückgabe, die sofort alle Kinder enthält. (Kemper & Eickler, 2001, S. 391) Ein Problem des Objekt-relationalen Datenbankmodells ist, dass der SQL:1999-Standard noch nicht für alle kommerzielle Datenbanksysteme übernommen wurde. Die meisten Datenbanksysteme verfügen nur über Teilkonzepte der oben genannten Erweiterungen. Dazu kommt, dass die Syntax dieser Konzepte nicht immer gleich ist. Dies führt dazu, dass keine Sicherheit darin besteht, wie das Objekt-relationale Datenmodell in dem vorliegenden Datensystem, implementiert wurde. Daher muss zunächst die Art der Programmierung recherchiert werden, um mit dem Konzept eine Datenbank entwickeln zu können. (Kemper & Eickler, 2001, S. 392) 12 3 Darstellung der zu verwaltenden Daten Das System, welches die Daten verwalten soll, muss in der Lage sein, mehrere Arten von Daten zu speichern, wie zum Beispiel Bilder und Wörter. Das System muss in der Lage sein verschiedene Fragen abspeichern zu können. Diese Fragen können Antwortmöglichkeiten haben, die mit der zugehörigen Frage verwaltet werden müssen. Außerdem sollte die Möglichkeit geboten werden, einen fertigen Fragebogen abzuspeichern. Das heißt nicht nur, dass es möglich sein muss, Fragen in verschiedenen Kombinationen abzuspeichern, sondern auch, dass die Anzahl der Fragen, die in einem Fragebogen enthalten sind, variabel ist. Deshalb ist es möglich, dass gleiche Fragen in mehreren Fragebögen vorkommen. Sobald ein neuer Fragebogen erstellt wurde, sollte das System die Möglichkeit bieten, Antworten im Rahmen dieses Fragebogens abzuspeichern. Dazu gehören zusätzlich noch personenspezifische Daten, die aber größtenteils gleich sind. Unter Probandendaten wird unter anderem das Alter oder das Geschlecht verstanden. 3.1 Fragetypen Im Folgenden werden die Möglichkeiten diskutiert, die gegeben werden sollen, um auf eine Frage zu antworten. Eine dieser Möglichkeit wären beispielsweise Mehrfach-Auswahl Fragen. 3.1.1 Die Antwort durch Selektion Die Antwortmöglichkeit durch Selektion kann in zwei verschiedenen Grundformen vorkommen. Möglich sind die Auswahl einer einzelnen und die Auswahl von mehreren Antworten. Die Einfach-Auswahl wird vor allem dann verwendet, wenn eine exakte Antwort aus einer Auswahl gewünscht ist. Eine Einfach-Auswahl Tests ist über solche Fragen aufgebaut. Hier werden verschiedene Fragen gestellt, auf die es immer genau eine richtige Antwort gibt. Es wird jedoch eine unbestimmte Anzahl von Antwortmöglichkeiten vorgeschlagen, wobei die richtige Antwort auf einem vorgesehenen Feld vermerkt werden muss. Die Mehrfachauswahl verhält sich etwas anders. Hierbei steht meistens eine große Auswahl an Antwortmöglichkeiten zur Verfügung, aus welcher der Befragte wählen kann. Es ist auch möglich, dass ein Bereich für die Anzahl der Selektionen angegeben ist. Eine Frage für die Mehrfachauswahl könnte zum Beispiel lauten: „Welche Elektronik Geräte besitzen Sie zu Hause? Bitte wählen Sie aus den folgenden Geräten aus.“ 13 3.1.2 Die schriftliche Antwort Eine weitere Antwortmöglichkeit, ist die Freitext Antwort. Diese Art von Antwort ermöglicht es, eine große Variation von Antworten zu erhalten. Diese Möglichkeit ist vor allem in Kombination mit anderen Fragetypen der Fall, wie zum Beispiel der Selektion. Hier können bei der Frage „Welche Elektronik Geräte haben sie in ihrer Küche?“ auch unübliche Dinge hinzufügt werden, die normalerweise ein Großteil der Haushalte nicht besitzt. Hier würde dann neben klassischen Dingen wie Herd und Kühlschrank auch ein nicht beschriftetes Feld zum Ankreuzen existieren, wo ein eigener Eintrag vorgenommen werden kann. 3.1.3 Strahl Eine andere Art auf eine Frage zu antworten, ist die Möglichkeit über einen Strahl zu antworten. Abbildung 1 – Strahl als Antwortmöglichkeit In Abbildung 1 wird ein Beispiel für einen solchen Strahl gezeigt. Möglich ist eine Erweiterung um weitere Beschriftungen, um den Probanden eine genauere Einschätzung zu ermöglichen und ihm einen besseren Überblick zu verschaffen. 3.1.4 Zahlenstrahl Eine abgewandelte Form des oben genannten Strahls ist ein Strahl der aus Ziffern und „*“ besteht. So ein Strahl beginnt normalerweise bei 0 und endet bei 9. Zwischen jeder dieser Ziffern ist ein „*“. 3.1.5 Fragen mit Zuordnung In Fragebögen können Fragen vorkommen, bei denen Zuordnungen gemacht werden müssen. Die Aufgabe könnte zum Beispiel so lauten: „In der nächsten Aufgabe sehen Sie verschiedene Begriffe. Bitte ordnen Sie diese ihrer jeweiligen Bedeutung zu.“ In der Aufgabe selbst werden dann mehrere Begriffe und mehrere Bedeutungen gegeben. Dabei sind die Anzahl der Begriffe und der Bedeutungen meistens unterschiedlich. So wird verhindert, dass nach dem Ausschlussverfahren vorgegangen werden kann. Manchmal hilft es jedoch auch, weil ein Begriff oder eine Bedeutung vorkommt, die nicht in den Kontext passt. Außerdem kann es sein, dass der Begriff durch ein Symbol ersetzt wird und diesem dann eine Bedeutung zugewiesen werden muss. 14 In Abbildung 2 kann man eine solche Frage richtig beantwortet sehen. 1 3 2 (1) nach oben (2) nach links (3) nach unten Abbildung 2 – Ein Beispiel für eine Zuordnung 3.1.6 Fragen mit Bildern Des Öfteren kommt es vor, dass Teile von Fragen durch Bilder ersetzt werden. Das dient nicht nur zur besseren Verdeutlichung der Frage, sondern ermöglicht auch ganz neue Fragen zu stellen. Solche Fragen können zum Beispiel die Möglichkeit bieten, das räumliche Vorstellungsvermögen zu testen. Dies kann durchgeführt werden, indem ein Würfel drei-dimensional abgebildet und so mit Symbolen versehen wird, dass eine eindeutige Bestimmung vorgenommen werden kann, in welche Richtung der Würfel gedreht wurde. Die Aufgabe besteht dann meistens darin, den gedrehten Würfel aus einer Auswahl von Würfeln zu finden und als Antwort zu markieren. 3.2 Sonstiges Des Weiteren müssen noch folgende Dinge bei der Implementierung der Daten beachtet werden. 3.2.1 Bilder Das System sollte in der Lage sein Bilder abzuspeichern, so wäre alles kompakt an einer Stelle. Dies würde dazu führen, dass Daten zum Beispiel beim Kopieren nicht einfach so verloren gehen oder es aus Versehen zu einer Änderung der Pfade von Bildern kommt. Dies führt dazu, dass die Verknüpfungen nicht mehr stimmen. Dadurch würden dann Fehler im Fragebogen entstehen, weil die Bilder nicht mehr gefunden werden würden. Um diesen Fehler zu beheben, müssten alle Bilder, die falsch verschoben wurden, wieder zurück verschoben werden oder der Pfad, der auf sie verweist, müsste geändert werden. 3.2.2 Mengenwertige Daten Bei allen Fragen, bei welchen eine Antwort selektiert werden kann, gibt es mehr als eine Antwortmöglichkeit. Da es keine feste Anzahl an Antworten geben soll, muss das Datenmodell in der Lage sein eine variable Menge an Antworten zu speichern. 15 3.2.3 Andere Informationen Das System muss außerdem in der Lage sein, Informationen zu den einzelnen Fragen abzuspeichern. Dies könnte zum Beispiel ein Bereich sein, der angibt, wie viele Antworten bei einer Frage selektiert werden können. Außerdem kann es sein, dass bei der „schriftlichen Antwort“ angeben wird, ob alpha-numerisch oder nur numerisch geantwortet werden kann, wenn beispielsweise das Alter angegeben werden soll. 16 4 Auswahl des Datenmodells In diesem Kapitel soll das entsprechende Datenmodell ausgewählt werden. Um diese Entscheidung treffen zu können, wurden Kriterien definiert, die für die Zielsetzung dieser Arbeit geeignet sind. Deshalb werden im Folgenden diese Kriterien kurz erläutert. 4.1 Erweiterbarkeit Einer der wichtigsten Punkte für die Auswahl des Datenmodells ist, dass sie erweiterbar ist. Erweiterbarkeit ist wichtig, weil des Öfteren Elemente vergessen werden oder eine besondere Art von Frage, die vorher noch nicht implementiert wurde, eingefügt werden soll. Das Datenmodell, welches am schwersten zu erweitern ist, ist die dateibasierte Datenverwaltung. Die anderen drei Modelle sind problemlos erweiterbar. 4.2 Flexibilität Ein weiterer wichtiger Punkt ist die Flexibilität. Flexibilität sorgt dafür, dass die Daten der realen Welt so originalgetreu wie möglich eingebaut werden. Je flexibler das Datenmodell ist, desto mehr und besser können die Daten ausgewertet werden. Besonders wichtig wird die Flexibilität vor allem, wenn die Daten mengenwertig sein können und keine feste Anzahl vorgegeben ist. Am flexibelsten sind die Objektorientierte und die Objekt-relationale Datenbank, da es sowohl möglich ist, eigene Objekte als auch Arrays anzulegen. Bei den anderen beiden Modellen ist Flexibilität nicht so einfach zu gewährleisten, da die Datenstruktur eines Arrays im Falle der relationalen Datenbank über eine neue Tabelle realisiert werden muss, während bei der dateibasierten Datenverwaltung eine Art Code gefunden werden muss, der dies ermöglicht. Dies führt dazu, dass die beiden Datenmodelle schnell unübersichtlich werden. 4.3 Struktur Die Datenstruktur sollte übersichtlich sein, damit sich neue Personen schnell in das System einfinden können. Eine gute Datenstruktur macht auch eine Implementierung von neuen Funktionen und einer Schnittstelle einfacher, weil die Verbindungen klar sind. Die beiden Datenmodelle, die die beste Struktur haben, sind das Objekt-relationale und die relationale Datenbank. Da beide über eine Tabelle aufgebaut sind, ist die Struktur immer gleich aufgebaut. Bei den anderen beiden Modellen ist die Struktur von der Implementierung abhängig. Dies kommt daher, dass die beiden Datenmodelle keine feste Struktur haben. 17 4.4 Modellierbarkeit Ein Punkt, der nicht außer Acht gelassen werden sollte, ist die Modellierbarkeit. Die Modellierbarkeit sagt etwas darüber aus, wie einfach die Implementierung von Informationen ist. Sowohl in der relationalen als auch in der Objekt-relationalen Datenbank wurden die Grundstrukturen für ein Datenmodell bereits erstellt. Es gibt einige Datentypen, wie zum Beispiel „int“ und „datetime“. Zusätzlich ist entweder das Relationenkalkül oder die relationale Algebra implementiert worden. Die Objektorientierte Datenbank hat auch einige Standarddatentypen implementiert, sowie eine Abfragesprache. Bei der dateibasierten Datenverwaltung wurde noch nichts implementiert, dies ermöglicht die freie Gestaltung der Datenstruktur. Dies ist aber auch mit einem hohen Entwicklungsaufwand verbunden, der sich nicht unbedingt lohnt. 4.5 Datensicherheit Ein anderer Punkt der Wichtig ist, ist die Datensicherheit. Datensicherheit heißt, dass die Daten erstens vor unbefugten Zugriff geschützt werden und zweitens, dass sie nicht verloren gehen können. Im Gegensatz zu dateibasierten Datenverwaltung muss bei Datenbanken eine Autorisierung vor dem Zugriff auf die Datenbank vorgenommen werden. Dafür werden ein Benutzername und ein Passwort benötigt. (Kemper & Eickler, 2001, S. 332) Viele Datenbanken bieten diese Möglichkeit über Datenbank-Dienstprogramme an. (Elmasri & Navathe, 2005, S. 51) 4.6 Standardisierung Ein wichtiger Punkt ist es außerdem, dass ein Datenmodell einem gewissen Standard unterliegt. Dieser Standard sorgt dafür, dass alles gewissen Regeln folgt und das Datenmodell immer nach dem gleichen Grundprinzip aufgebaut ist. Dies sorgt dafür, dass ein bestimmtes Datenmodell nur einmal gelernt werden muss. So wird eine Recherche vermieden, wenn eine andere Realisierung des gleichen Datenmodelles benutzt wird. Dies kann viel Zeit sparen. Außerdem kann ein über längeren Zeitraum durchgesetzter Standard dazu führen, dass die dazu gehörigen Produkte im Preis sinken und so kostengünstig bis kostenlos angeboten werden können. Den besten umgesetzten Standard hat die relationale Datenbank. Die Objektorientierte Datenbank hat zwar einen Standard, dieser hat sich jedoch noch nicht so gut durchgesetzt, wie der Standard der relationalen Datenbank. Bei der Objekt-relationalen Datenbank wurde zwar auch ein Standard gesetzt, jedoch gab es keine allgemeine Umsetzung von diesem Standard. Dies ist wie für die dateibasierte Datenverwaltung ein Nachteil, wobei die dateibasierte Datenverwaltung keinen Standard hat, sondern immer von der Anwendung abhängt. 18 4.7 Programmiersprache Ein anderer Punkt, der betrachtet werden sollte, ist die Programmiersprache, über die mit einer Schnittstelle auf die Datenbank zugegriffen wird. Die Objektorientierte Datenbank bietet nur die Möglichkeit, eine Schnittstelle über C++ oder Smalltalk zu benutzen, während es die anderen Datenmodelle ermöglichen in vielen Programmiersprachen auf das Datenmodell zuzugreifen. Andere Programmiersprachen wären zum Beispiel C#, Java und PHP. 4.8 Auswahl des Datenmodells anhand der Kriterien Um ein Datenmodell auszuwählen, wird vorher noch kurz eine Wertung der einzelnen Kriterien abgegeben, um so eine Auswahl leichter treffen zu können. Ein Punkt der für das Projekt sehr wichtig ist, ist, dass später andere Personen an der Datenbank und an der Anwendung arbeiten können. Dafür sind eine übersichtliche Struktur und ein gewisser Standard natürlich wichtig. Etwas weniger wichtig ist außerdem die Erweiterbarkeit und die Flexibilität, da des Öfteren verschiedene Fragetypen leicht abgewandelt vorkommen können oder ein Datensatz erweitert werden soll. Die restlichen Punkte sind dann ungefähr gleich wichtig. Nachdem die Kriterien betrachtet wurden, soll nun ein geeignetes Datenmodell ausgewählt werden. Es wurde nicht zu Gunsten der dateibasierten Datenverwaltung entschieden, weil die Nachteile die Vorzüge überwiegen. Eine der größeren Nachteile entsteht vor allem durch die Datenunsicherheit, weil diesbezüglich noch nichts von vorneherein implementiert wurde. Wegen mangelnder Standards bei der Implementierung wurde die Objekt-relationale Datenbank nicht ausgewählt, obwohl mengenwertige Attribute zwar oft von Vorteil, aber nicht zwangsläufig nötig wären. Die Objektorientierte Datenbank wurde ebenfalls nicht ausgewählt, da sie nicht bei vielen Leuten bekannt ist. Wenn das Projekt an eine andere Person weitergegeben würde, um es zu pflegen und zu erweitern, müsste sich diese zuerst in Objektorientierte Datenbanken einlesen. Das Datenmodell, was alles ermöglicht das gewünscht ist, ist die relationale Datenbank. Der Standard, der über Jahre hinweg weiterentwickelt und implementiert wurde, ist ein großer Vorteil. Außerdem ist dies ein Datenmodell, welches sehr weit verbreitet ist, weil es sich durch seine simple Struktur und die Nutzungsmöglichkeiten durchgesetzt hat. Es entsteht ein Nachteil dadurch, dass keine mengenwertige Attribute oder eigene Objekte möglich sind, aber dies kann man dank SQL leicht umgehen. 19 5 Aufbau der Datenbank Im Folgenden soll die Grundstruktur der Datenbank beschrieben und danach ein Beispiel anhand eines vorhandenen Fragebogens gegeben werden. 5.1 Grundstruktur Die Datenbank selbst wird aus mehreren Tabellen bestehen. Eine Tabelle wird verschiedene Fragen abspeichern. Für die Fragebögen selber sollen zwei Tabellen angelegt werden. In der einen soll der Name des Fragebogens abgespeichert werden, während in der anderen die Fragen in Kombination mit dem Fragebogen zusammengebracht werden. Zu jedem Fragebogen soll eine weitere Tabelle erstellt werden, in der dann die Beantwortungen der Fragen von verschiedenen Personen abgespeichert werden. Um die Struktur übersichtlicher zu halten, soll eine weitere Tabelle zur Speicherung der Probanden angelegt werden. Dadurch wird Redundanz vermieden, weil nicht in jeder Tabelle gleiche Daten über den Probanden abgespeichert werden müssen, sondern mit einer Referenz auf die Informationen über den Probanden verwiesen wird. 5.2 Fragen-Katalog Eine der wichtigsten Bestandteile der Datenstruktur soll eine Tabelle ausmachen, in denen komplette Fragen abgespeichert werden sollen. Jede Frage muss eine Fragestellung und einen Fragentyp, wie in Kapitel 3.1 beschrieben, beinhalten. Außerdem ist es sinnvoll eine „Fragen-ID“ einzuführen, damit aus anderen Tabellen darauf verwiesen werden kann. Um dies in der relationalen Datenbank umzusetzen muss für jeden Fragentyp ein Attribut angelegt werden. Zusätzlich zu den bereits genannten Informationen, erfordern gewisse Fragetypen weitere Informationen. Diese Informationen umfassen unter anderem mehrere Antwortmöglichkeiten zu den Fragen. Diese Daten könnten in einer zusätzlichen Tabelle gespeichert werden. In dieser Tabelle gäbe es dann zwei Attribute, wobei das eine die „Fragen-ID“ und das andere die Antwortmöglichkeit beinhalten würde. Zusätzlich müssten noch Spalten hinzugefügt werden, die angeben wie viel die minimale und die maximale Anzahl ist, die der Proband der Frage auswählen darf. Wenn die Frage ausgelesen wird, werden alle Antwortmöglichkeiten wegen der Referenz mit der Frage verbunden. Ähnliches soll für die beiden Möglichkeiten gelten, die einen Strahl benutzen. Für beide Fälle soll es die Möglichkeit geben, Beschriftungen an die Ränder zu setzen, wobei dies nur beim normalen Strahl verpflichtend sein soll. Zusätzlich müssen für den Zahlenstrahl eine minimale und eine maximale Zahl angegeben werden können. 20 Die Zuweisung zu implementieren wird ähnlich ablaufen wie der Rest, auch für diesen Fragentyp wird eine neue Tabelle erstellt. Sie soll neben der „Fragen-ID“ noch zwei weitere Felder beinhalten. In dem einen wird das gefragte Symbol oder Wort eingetragen, während in dem anderen die passende Beschreibung steht. Diejenigen, die zusätzlich da sind und somit keine passende Zuweisung haben, werden trotzdem in die Tabelle eingefügt, jedoch wird eines der beiden Felder leer bleiben. Die schriftliche Antwort benötigt keine weitere Tabelle, da es hier völlig ausreicht im Fragetypen zwischen einem numerischen und einem alpha-numerischen Fragetypen zu unterscheiden. 5.3 Probanden-Daten Ein Weg, Informationen über die Probanden abzuspeichern, ist, die Informationen in einer Tabelle abzuspeichern. Das ist deshalb besonders nützlich, da die allgemeinen Daten in atomare Werte unterteilt werden können und keine mengenwertigen Attribute vorkommen. Da jeder Proband eine „Probanden-ID“ hat, kann dieses Feld als Primär-Schlüssel benutzt werden. Über diese ID kann er dann mit seinen Antworten zu verschiedenen Fragebögen verknüpft werden. Diese Tabelle sollte später noch erweiterbar sein, falls für spätere Fragebögen weitere allgemeine Daten über den Probanden wichtig werden. Dies könnte zum Beispiel der höchste Abschluss sein. 5.4 Fragebögen Die Fragebögen selbst sollen aus einer Kombination von Fragen bestehen. Dafür sollen zwei Tabellen angelegt werden, eine die eine „Fragebogen-ID“ und einen „Namen“ als Attribut enthält und eine andere, die als Attribute eine „Fragen-ID“ und eine „Fragebogen-ID“ besitzt. Um einen Fragebogen in die Datenbank einzufügen, muss er einmalig in die erste Tabelle eingefügt werden, indem er dort eine „Fragebogen-ID“ zugewiesen bekommt und der Name eingetragen wird. Um die Fragen für den Fragebogen festzulegen, soll in die zweite Tabelle für jede Frage, die vorkommt, die passende Kombination von „Fragebogen-ID“ und „Fragen-ID“ hinzugefügt werden. Wenn ein neuer Fragebogen in die Tabelle eingefügt wird, soll außerdem eine weitere Tabelle erstellt werden, die für jede Frage eine eigene Spalte hat, um dort die Antworten der Probanden abzuspeichern. Zusätzlich soll es noch eine Variable „Versuchs-Nummer“ geben, da es ein kann, dass der gleiche Proband denselben Fragebogen mehrfach beantwortet. In Abbildung 3 kann man den Aufbau eines fiktiven Fragebogens und dem Zusammenhang zu dem Probanden sehen. 21 Abbildung 3 – Beziehung zwischen Probanden- und Fragebogen-Auswertung-Tabelle (Dia (Version 0.97.1) [Eine Anwendung zum Zeichnen von strukturierten Diagrammen.]) 22 6 Ausblick auf die Bachelorarbeit Die relationale Datenbank und die Struktur soll die Grundlage für eine Implementierung der Fragebögen bilden. Ein weiterer wichtiger Schritt für die Implementierung der Fragebögen ist die Entwicklung einer Schnittstelle mit der es möglich ist, auf die Datenbank zugreifen zu können. Dieser Zugriff soll sowohl lesen, als auch auf der Datenbank schreiben können. Eventuell kann es auch von Nöten sein, Dinge auf der Datenbank verändern und löschen zu können. Zusätzlich soll es möglich sein, die Fragebögen digital auswerten zu können. Dies soll natürlich in einem anschaulichen Rahmen geschehen, so dass der einzige große Unterschied zwischen der digitalen und den Fragebögen auf Papier der Computer ist. Diese digitale Auswertung muss auch in der Lage sein, neue Fragebögen zu erstellen. Deshalb kann es eventuell notwendig sein, die Möglichkeit zu bieten, neue Fragen hinzuzufügen. Zusätzlich wäre eine Implementierung gut, die es ermöglicht Fragebögen auszuwerten. Außerdem muss natürlich die relationale Datenbank, wie sie oben beschrieben ist, eingerichtet und implementiert werden. Sollte das alles geschehen sein, ist es wichtig sowohl die Anwendung als auch die Datenbank zu testen. Die Bachelorarbeit befasst sich mit der Implementierung der Schnittstelle und der endgültigen Modellierung der Datenbank. 23 7 Fazit Zunächst wurden verschiedene Datenmodelle miteinander verglichen. Dadurch hat sich aber kein Datenmodell besonders hervorgehoben. Aus diesem Grund mussten noch die verschiedenen Daten, die verwaltet werden sollen, beschrieben werden. Anhand bestimmter Kriterien wurden dann verschiedene Arten von Datenmodellen bewertet. Um das Ergebnis zu veranschaulichen, werden diese Kriterien und die relevanten Bewertungen noch einmal in Tabelle 1 zusammengefasst. Tabelle 1 – Ergebnisse der Bewertung Dateibasierte Relationale Objektorientierte Objekt-relationale Datenverwaltung Datenbank Datenbank Datenbank Erweiterbarkeit befriedigend gut sehr gut sehr gut Flexibilität mangelhaft gut sehr gut sehr gut Struktur abhängig sehr gut abhängig gut Datensicherheit mangelhaft gut gut gut Standardisierung mangelhaft sehr gut befriedigend mangelhaft große Auswahl kleine Auswahl große Auswahl gut befriedigend befriedigend Programmiersprache große Auswahl Ergebnis: mangelhaft Aus der Tabelle kann entnommen werden, warum die relationale Datenbank ausgewählt wurde. Diese Entscheidung hat sich im Kapitel, in welchem die Daten in die Datenbank eingefügt wurden, als richtig herausgestellt, da es keine Probleme gab, die Daten in ein relationales Datenmodell einzufügen. 24 Literaturverzeichnis Elmasri, R., & Navathe, S. B. (2005). Grundlagen von Datenbanksystemen: Ausgabe Grundstudium. München: Pearson Education Deutschland GmbH. Kemper, A., & Eickler, A. (2001). Datenbanksysteme: eine Einführung. München: Oldenbourg Wissenschaftsverlag GmbH. The Free Software Foundation and the authors. (2010). Dia (Version 0.97.1) [Eine Anwendung zum Zeichnen von strukturierten Diagrammen.]. Boston: The Free Software Foundation. A Anhang Abbildung 1 – Strahl als Antwortmöglichkeit ............................................................................... 14 Abbildung 2 – Ein Beispiel für eine Zuordnung ............................................................................ 15 Abbildung 3 – Beziehung zwischen Probanden- und Fragebogen-Auswertung-Tabelle .............. 22 Tabelle 1 – Ergebnisse der Bewertung ........................................................................................... 24 25 Eidesstattliche Erklärung Hiermit versichere ich, dass ich die Seminararbeit mit dem Thema „Digitale Datenverwaltung im Rahmen arbeitswissenschaftlicher Untersuchungen“ selbstständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel benutzt habe, alle Ausführungen, die anderen Schriften wörtlich oder sinngemäß entnommen wurden, kenntlich gemacht sind und die Arbeit in gleicher oder ähnlicher Fassung noch nicht Bestandteil einer Studien- oder Prüfungsleistung war. Name: Carina Huchler Aachen, den 15.12.2011 ______________________ Unterschrift der Studentin 26
