Difference between revisions of "4. Lehreinheit"
From DHVLab
(Created page with "<code>(//Abbildung der vorangehenden, bereinigten Calc-Datei einbinden)</code><br \> Bei der vorangehenden Übung haben wir damit begonnen, Inhalte sauber strukturiert abzule...") |
|||
Line 1: | Line 1: | ||
<code>(//Abbildung der vorangehenden, bereinigten Calc-Datei einbinden)</code><br \> | <code>(//Abbildung der vorangehenden, bereinigten Calc-Datei einbinden)</code><br \> | ||
− | Bei der vorangehenden Übung haben wir damit begonnen, Inhalte sauber strukturiert abzulegen und Informationen auf verschiedene Tabellenspalten sinnvoll aufzugliedern. | + | === Besprechung ausgewählter Teilnehmer-Tabellen === |
+ | Bei der vorangehenden Übung haben wir damit begonnen, Inhalte sauber strukturiert abzulegen und Informationen auf verschiedene Tabellenspalten sinnvoll aufzugliedern.<br \> | ||
+ | Vorbereitend zu dieser Sitzung, sollten die Teilnehmer einen Abschnitt aus der Liste nach Lauro (ges. 10 Personen) sinnvoll strukturieren. Im Folgenden werden drei der Einsendungen als ausgewählte Beispiele besprochen: | ||
+ | <br \> | ||
+ | Datei 1: | ||
+ | <code>(//Datei 1 einfügen)</code> | ||
+ | * Geographisch gegliedert (Je ein Tabellenblatt/Land, darin den entsprechenden Verwaltungsebenen die Begräbnisstätten zugeordnet und diesen wiederum die Personen samt Lebensdaten) | ||
+ | * Für eine überschaubare Anzahl an Personen mag dieses Verfahren noch anwendbar sein; sobald jedoch die Zahl der Datensätze ansteigt, wird es hier schnell unübersichtlich | ||
+ | * Rudolf Franz (1822-1822) wird an zwei verschiedenen Orten begraben. Es wäre daher sinnvoll, die Personen separat zu sammeln und sie über einen Identifier mit den entsprechenden Grabstätten zu verknüpfen → Redundanz vermeiden, da fehleranfällig und mit Mehraufwand verbunden bei Überarbeitung | ||
+ | * Ferner wird es in vorliegendem Beispiel schwierig, die einzelnen Objekten mit Zusatzinformationen anzureichern (z.B. Wikipedia-Artikel); diese müssten hier ebenfalls mehrfach eingetragen werden. | ||
+ | * Daten sind nicht quantifizierbar. In der vorliegenden Form könnten keine statistischen Auswertungen erfolgen. | ||
+ | <br \> | ||
+ | Datei 2:<br \> | ||
+ | <code>(//Datei 2 einfügen)</code><br \> | ||
+ | * Datei 2 besteht aus einer Haupttabelle und einer Nebentabelle mit ergänzenden Informationen. Positiv hervorzuheben ist, dass Informationen auf verschiedene Spalten aufgeteilt werden und jede Zeile dabei einen Datensatz darstellt. Den Personen werden Informationen zur Grabstätte sowie Normdaten (GND) beigegeben | ||
+ | * Positiv ist ebenfalls die Strukturierung der Daten, wenngleich in manchen Fällen nicht unbedingt erforderlich (z.B. könnten Name und Zusatz in einer Spalte zusammengefasst werden) | ||
+ | * Verbesserungswürdig ist Verknüpfung der Informationen; diese erfolgt in diesem Beispiel über die Geokoordinaten, welche in Tabelle 2 um den jeweiligen Ort ergänzt werden. Zielführend wäre der Einsatz von IDs. | ||
+ | * Problematisch ist ebenfalls die Redundanz der eingetragenen Daten, insb. der Geodaten. | ||
+ | <br \> | ||
+ | Datei 3:<br \> | ||
+ | <code>(//Datei 3 einfügen)</code><br \> | ||
+ | * Dieser Teilnehmer hat seine Daten in verschiedenen Tabellen abgelegt und diese durch den Einsatz von IDs miteinander in Verbindung gesetzt. | ||
+ | * Informationen werden dadurch quantifizierbar | ||
+ | * In einigen Fällen könnte noch stärker normalisiert werden (z.B. Trennung Name und Lebensdaten), in anderen Fällen geht die Aufteilung der Informationen etwas über das Ziel hinaus (z.B. Ort und Land → in eine Tabelle) | ||
+ | * Zuordnung der Sakralbauten und Grabstätten erscheint problematisch: Wird eine Person an mehreren Orten begraben, so werden zwar "Gruft" und "Sakralbau" genannt, jedoch nur eine Ortsangabe. Eine georeferenzierte Darstellung wäre in diesen Fällen nicht möglich. | ||
+ | |||
+ | === Einstieg in die Datenstrukturierung === | ||
+ | → Für umfassende Informationen sei auf "[[Das relationale Datenmodell - Theoretische Grundlagen I]]" verwiesen. | ||
+ | In den gezeigten Beispielen gibt es gute Ansätze zur Strukturierung der Forschungsdaten. Jedoch tritt zuweilen eine noch recht "geisteswissenschaftliche Vorstellung" von Tabellen zutage, d.h. es gilt noch stärker zu verstehen, warum Daten strukturiert in verschiedenen Tabellen und Spalten abgelegt werden sollten und auf welche Art und Weise dies in einer relationalen Datenbank erfolgt. | ||
+ | <br \><br \> | ||
+ | Warum werden Daten in verschiedenen Tabellen abgelegt? | ||
+ | * Vermeidung von Redundanz - Stichwort: Normalisieren, d.h. Daten sollten möglichst nicht wiederkehrend, sondern an zentraler Stelle einmalig abgelegt werden. Dadurch wird sichergestellt, dass | ||
+ | * die Konsistenz der Daten erhalten bleibt; eine Änderung am Datenbestand muss also nur an einer Stelle durchgeführt werden. In manchen der oben angeführten Beispiele müsste man bei der Änderung einer Information an verschiedenen Stellen suchen und die Ausbesserung vornehmen | ||
+ | * die Datenmenge übersichtlich und überschaubar bleibt. | ||
+ | * möglichst viele Zusatzinformationen an nur einer Stelle in der Datenbank eingebettet werden können. | ||
+ | <br \> | ||
+ | Zur Einbindung der Informationen in andere Tabellen werden eindeutige Schlüssel (ID) verwendet bzw. eigene Tabellen angelegt, die nur zur Zuordnung verschiedener Objekte und Merkmale dienen. Die Verknüpfung erfolgt stets über die ID, die jeden Datensatz, d.h. jede Zeile einer Tabelle eindeutig identifizierbar macht. | ||
+ | <br \><br \> | ||
+ | Ein guter Ansatzpunkt um festzustellen, an welcher Stelle ein weiteres Aufsplitten von Informationen sinnvoll sein könnte, ist das Sortieren nach bestimmten Informationen. In manchen der oben angeführten Beispiele wäre es zum Beispiel nicht möglich, nach den Geburts- oder Sterbejahren zu sortieren, wenn sich diese in derselben Spalte wie der Personenname befindet. | ||
+ | Dadurch wird auch die Quantifizierbarkeit der Informationen negativ beeinflusst, da z.B. nicht danach gefiltert werden kann, wie viele Personen im Zeitraum XXXX-YYYY gestorben sind. | ||
+ | <br \><br \> | ||
+ | Um sich Klarheit über die Datenbasis und ihre sinnvolle Strukturierung noch vor der Erstellung der späteren Datenbank zu verschaffen, hilft die Anlage eines sogenannten Entity-Relationship-Modells (ERM). Dieses wird in der folgenden Sitzung theoretisch erklärt und praktisch anhand der besprochenen Beispieldaten umgesetzt. |
Revision as of 19:56, 15 March 2017
(//Abbildung der vorangehenden, bereinigten Calc-Datei einbinden)
Besprechung ausgewählter Teilnehmer-Tabellen
Bei der vorangehenden Übung haben wir damit begonnen, Inhalte sauber strukturiert abzulegen und Informationen auf verschiedene Tabellenspalten sinnvoll aufzugliedern.
Vorbereitend zu dieser Sitzung, sollten die Teilnehmer einen Abschnitt aus der Liste nach Lauro (ges. 10 Personen) sinnvoll strukturieren. Im Folgenden werden drei der Einsendungen als ausgewählte Beispiele besprochen:
Datei 1:
(//Datei 1 einfügen)
- Geographisch gegliedert (Je ein Tabellenblatt/Land, darin den entsprechenden Verwaltungsebenen die Begräbnisstätten zugeordnet und diesen wiederum die Personen samt Lebensdaten)
- Für eine überschaubare Anzahl an Personen mag dieses Verfahren noch anwendbar sein; sobald jedoch die Zahl der Datensätze ansteigt, wird es hier schnell unübersichtlich
- Rudolf Franz (1822-1822) wird an zwei verschiedenen Orten begraben. Es wäre daher sinnvoll, die Personen separat zu sammeln und sie über einen Identifier mit den entsprechenden Grabstätten zu verknüpfen → Redundanz vermeiden, da fehleranfällig und mit Mehraufwand verbunden bei Überarbeitung
- Ferner wird es in vorliegendem Beispiel schwierig, die einzelnen Objekten mit Zusatzinformationen anzureichern (z.B. Wikipedia-Artikel); diese müssten hier ebenfalls mehrfach eingetragen werden.
- Daten sind nicht quantifizierbar. In der vorliegenden Form könnten keine statistischen Auswertungen erfolgen.
Datei 2:
(//Datei 2 einfügen)
- Datei 2 besteht aus einer Haupttabelle und einer Nebentabelle mit ergänzenden Informationen. Positiv hervorzuheben ist, dass Informationen auf verschiedene Spalten aufgeteilt werden und jede Zeile dabei einen Datensatz darstellt. Den Personen werden Informationen zur Grabstätte sowie Normdaten (GND) beigegeben
- Positiv ist ebenfalls die Strukturierung der Daten, wenngleich in manchen Fällen nicht unbedingt erforderlich (z.B. könnten Name und Zusatz in einer Spalte zusammengefasst werden)
- Verbesserungswürdig ist Verknüpfung der Informationen; diese erfolgt in diesem Beispiel über die Geokoordinaten, welche in Tabelle 2 um den jeweiligen Ort ergänzt werden. Zielführend wäre der Einsatz von IDs.
- Problematisch ist ebenfalls die Redundanz der eingetragenen Daten, insb. der Geodaten.
Datei 3:
(//Datei 3 einfügen)
- Dieser Teilnehmer hat seine Daten in verschiedenen Tabellen abgelegt und diese durch den Einsatz von IDs miteinander in Verbindung gesetzt.
- Informationen werden dadurch quantifizierbar
- In einigen Fällen könnte noch stärker normalisiert werden (z.B. Trennung Name und Lebensdaten), in anderen Fällen geht die Aufteilung der Informationen etwas über das Ziel hinaus (z.B. Ort und Land → in eine Tabelle)
- Zuordnung der Sakralbauten und Grabstätten erscheint problematisch: Wird eine Person an mehreren Orten begraben, so werden zwar "Gruft" und "Sakralbau" genannt, jedoch nur eine Ortsangabe. Eine georeferenzierte Darstellung wäre in diesen Fällen nicht möglich.
Einstieg in die Datenstrukturierung
→ Für umfassende Informationen sei auf "Das relationale Datenmodell - Theoretische Grundlagen I" verwiesen.
In den gezeigten Beispielen gibt es gute Ansätze zur Strukturierung der Forschungsdaten. Jedoch tritt zuweilen eine noch recht "geisteswissenschaftliche Vorstellung" von Tabellen zutage, d.h. es gilt noch stärker zu verstehen, warum Daten strukturiert in verschiedenen Tabellen und Spalten abgelegt werden sollten und auf welche Art und Weise dies in einer relationalen Datenbank erfolgt.
Warum werden Daten in verschiedenen Tabellen abgelegt?
- Vermeidung von Redundanz - Stichwort: Normalisieren, d.h. Daten sollten möglichst nicht wiederkehrend, sondern an zentraler Stelle einmalig abgelegt werden. Dadurch wird sichergestellt, dass
- die Konsistenz der Daten erhalten bleibt; eine Änderung am Datenbestand muss also nur an einer Stelle durchgeführt werden. In manchen der oben angeführten Beispiele müsste man bei der Änderung einer Information an verschiedenen Stellen suchen und die Ausbesserung vornehmen
- die Datenmenge übersichtlich und überschaubar bleibt.
- möglichst viele Zusatzinformationen an nur einer Stelle in der Datenbank eingebettet werden können.
Zur Einbindung der Informationen in andere Tabellen werden eindeutige Schlüssel (ID) verwendet bzw. eigene Tabellen angelegt, die nur zur Zuordnung verschiedener Objekte und Merkmale dienen. Die Verknüpfung erfolgt stets über die ID, die jeden Datensatz, d.h. jede Zeile einer Tabelle eindeutig identifizierbar macht.
Ein guter Ansatzpunkt um festzustellen, an welcher Stelle ein weiteres Aufsplitten von Informationen sinnvoll sein könnte, ist das Sortieren nach bestimmten Informationen. In manchen der oben angeführten Beispiele wäre es zum Beispiel nicht möglich, nach den Geburts- oder Sterbejahren zu sortieren, wenn sich diese in derselben Spalte wie der Personenname befindet.
Dadurch wird auch die Quantifizierbarkeit der Informationen negativ beeinflusst, da z.B. nicht danach gefiltert werden kann, wie viele Personen im Zeitraum XXXX-YYYY gestorben sind.
Um sich Klarheit über die Datenbasis und ihre sinnvolle Strukturierung noch vor der Erstellung der späteren Datenbank zu verschaffen, hilft die Anlage eines sogenannten Entity-Relationship-Modells (ERM). Dieses wird in der folgenden Sitzung theoretisch erklärt und praktisch anhand der besprochenen Beispieldaten umgesetzt.