Datenbanken - Vertiefung

Ein Datenbanksystem (DBS) ist ein System zur elektronischen Verwaltung gro√üer Datenmengen, um diese effizient, widerspruchsfrei und dauerhaft zu speichern und in den ben√∂tigten Teilmengen in unterschiedlichen Darstellungsformen f√ľr Benutzer und Anwendungsprogramme bereitzustellen. Gegen√ľber einer Speicherung in strukturierten Einzeldateien, wie Tabellen, werden unter anderem folgende Probleme effizienter gel√∂st:

  • Redundanzen: Bei einer Speicherung in Einzeldateien werden viele Daten mehrfach gespeichert. √Ąnderungen werden dadurch sehr aufwendig, da sie an verschiedenen Stellen durchgef√ľhrt werden m√ľssen.
  • Inkonsistenzen: Sowohl bei der gleichzeitigen √Ąnderung von Daten durch mehrere Benutzer als auch bei √Ąnderungen von redundanten Daten kann es leicht zu Widerspr√ľchen und Inkonsistenzen in den Daten kommen, was mit der Verwendung von DBS vermieden wird.
  • Integrit√§tsbedingungen: Sofern einzelne oder globale Informationen direkt von anderen Informationen abh√§ngen, lassen sich entsprechende Bedingungen in der Datenbank abbilden, die bei der Eingabe neuer Informationen eine Kontrollfunktion √ľbernehmen und dadurch bestimmte Fehler in den Daten verhindern k√∂nnen.
  • Datenschutzprobleme: Einzeldateien besitzen kein dezidiertes User-Management, weswegen ein Zugriff auf den gesamten Datenbestand vorliegt, wohingegen DBS differenzierte Zugriffsregelungen erm√∂glichen.
  • Darstellungsvarianten: Mit einem DBS lassen sich verschiedene Ausschnitte, sog. Sichten (engl. views), aus der Gesamtmenge aller gespeicherten Informationen erstellen und so einmal eingetragene Informationen f√ľr unterschiedliche Zwecke und Nutzer variabel anzeigen (z.B. in einem Eingabeformular, als tabellarische √úbersicht oder vorformatiert f√ľr eine Publikation).

datenbanken_vergleich.png

Vergleich von Datenhaltung in Einzeldateien (links) gegen√ľber Datenhaltung mit Hilfe eines Datenbanksystems (rechts).
Vergleich von Datenhaltung in Einzeldateien (links) gegen√ľber Datenhaltung mit Hilfe eines Datenbanksystems (rechts).
Ein DBS besteht aus der Verwaltungssoftware, genannt Datenbankmanagementsystem (DBMS), und der Menge der zu verwaltenden Informationen, der eigentlichen Datenbank (DB). Die Datenbank enthält zusätzlich zu den eigentlichen Inhalten noch die Beschreibung der Datenstruktur, die in einem Datenkatalog und in einem Datenbankschema mittels Metadaten festgehalten wird.

Bei einem DBMS handelt es sich um ein Programm (kommerzielle Produkte sind u. a. FileMakerPro, Access und Oracle, OpenSource sind u. a. MySQL und PostgreSQL), das als Steuerungsprogramm intern die strukturierte Speicherung der Daten organisiert und alle lesenden und schreibenden Zugriffe auf die Datenbank ausf√ľhrt. Der Benutzer greift also nicht direkt auf die Datenbank zu, sondern auf das DBMS als Kontrollinstanz. Die Aufgaben eines DBMS umfassen u. a. folgende Bereiche:

  • Eingabe, √Ąnderung und L√∂schen von Daten
  • Erstellen von Datenbanken inklusive Umsetzung des Datenmodells
  • Suchen in den Datenbankinhalten mittels Abfragen
  • generelle Verwaltung von Benutzern, Zugriffen und Zugriffsrechten

Der Begriff Datenbank (DB) bezieht sich auf die eigentlichen Sachdaten, die entweder von Benutzern manuell eingegeben oder automatisch generiert werden. Die Datenbankinhalte können in unterschiedlichen Formaten vorliegen und als Texte, Zahlen, Links oder Medien (Fotos, Zeichnungen, Filme etc.) in die Datenbank einfließen. Dieser Datenbestand wird von einem DBMS verwaltet, auf Speichermedien abgelegt und je nach Vorgabe kontrolliert (damit z. B. ein Funddatum immer auch einem Fund zugeordnet ist).

Datenbankmodelle

Zur formalen Beschreibung aller in der Datenbank enthaltenen Daten, ihrer Speicherung und ihrer Beziehungen untereinander verwendet man auf der konzeptionellen Ebene ein Datenmodell. Es ist die konzeptuelle Grundlage f√ľr ein Datenbanksystem und legt fest, auf welche Art und Weise der jeweils interessierende Ausschnitt aus der realen Welt in einer Datenbank abgebildet wird.

Es gibt verschiedene Datenmodelle, von denen das relationale das am weitesten verbreitete ist.

Relationales Datenmodell: Bei Relationalen Datenbanken (untenstehende Abbildung) werden die Daten sowie deren Beziehungen untereinander in Form von Tabellen (Relationen) beschrieben. Die einzelnen Einträge in unterschiedlichen Tabellen können mittels Verweise miteinander in Beziehung gesetzt werden.

datenbanken_relationaleDBs-web.png

Beispiel einer relationalen Datenbank anhand von M√ľnzdaten
Beispiel einer relationalen Datenbank anhand von M√ľnzdaten

Hierarchisches Datenmodell: Bei hierarchischen Datenbanken (untenstehende Abbildung) werden die Informationen in Datensätze gruppiert und in einer baumartigen Datenstruktur gespeichert, die einer Mutter-Kind-Beziehung entspricht: Jede Mutter kann mehrere Kinder haben, ein Kind aber nur eine Mutter besitzen.

datenbanken_hierarchischeDBs-web.png

Beispiel einer hierarchischen Datenbank anhand von M√ľnzdaten
Beispiel einer hierarchischen Datenbank anhand von M√ľnzdaten

Netzwerk Datenmodell: Netzwerkdatenbanken (untenstehende Abbildung) stellen eine Verallgemeinerung und Weiterentwicklung des hierarchischen Datenmodells dar, wobei die Daten in logischen Graphen strukturiert werden. Da die einzelnen Knoten im Graph beliebig miteinander √ľber Beziehungen verkn√ľpft werden k√∂nne, entfallen die Beschr√§nkungen, die mit Mutter-Kind-Beziehungen einhergehen.

datenbanken_netzwerkDBs-web.png

Beispiel einer Netzwerkdatenbank anhand von M√ľnzdaten
Beispiel einer Netzwerkdatenbank anhand von M√ľnzdaten

Objektorientiertes Datenmodell: Analog zu den objektorientierten Programmiersprachen versuchen objektorientierte Datenbanken (untenstehende Abbildung) Objekte aus der realen Welt mit ihren Eigenschaften und ihrem Verhalten nachzubilden. Die Definition der Objekte erfolgt √ľber Klassen, welche Attribut- und Verhaltensdefinitionen enthalten und als Bauplan f√ľr daraus erzeugte Objekte fungieren.

datenbanken_objektorientierteDBs-web.png

Beispiel einer objektorientierten Datenbank anhand von M√ľnzdaten
Beispiel einer objektorientierten Datenbank anhand von M√ľnzdaten

NoSQL Datenmodell: Der Begriff NoSQL steht f√ľr "Nicht nur SQL" (Not only SQL) und bezeichnet Datenbanken, welche kein relationales Datenschema, sondern andere Paradigmen verfolgen. Sie k√∂nnen in zwei Typen unterschieden werden:

  • Bei dokumentenorientierten Datenbanken wird die zusammengeh√∂rige Informationsmenge in einem einzelnen Dokument gespeichert. Die Daten werden in Feldname-Wert-Paaren (z. B. Datierung: R√∂misch) z.B. im JSON Format gespeichert, wobei nicht jedes Paar vorhanden sein muss, was eine gewisse Flexibilit√§t erlaubt.
  • Graphen-Datenbanken k√∂nnen als moderne Nachfolger von Netzwerkdatenbanken verstanden werden, die vor allem bei sehr stark vernetzten Daten verwendet werden. Auch hier werden mit Hilfe von Graphen die Daten als Knoten dargestellt und die Beziehungen zwischen Ihnen als Kanten, wobei sowohl die Knoten als auch die Kanten Eigenschaften besitzen.
 {
    "id":1,
    "Fundstellen_Name":"Korinth",
    "Breite"':37.91,
    "Länge"':22.87,
¬†¬† ¬†"M√ľnzen"'[
        {
            "id":23,
¬†¬† ¬†¬†¬† ¬†¬†¬† ¬†"M√ľnzen_Name":"Commodus aus Korinth",
            "Metall":"Bronze",
            "Fotos":[
                {
                    "id":49,
                    "Foto_Name":"Fundfoto -- Avers"
                },
                {
                    "id":50,
                    "Foto_Name":"Fundfoto -- Revers"
                }
            ]
        },
        {
            "id":24,
¬†¬† ¬†¬†¬† ¬†¬†¬† ¬†"M√ľnzen_Name":"M√ľnze aus Korinth",
            "Metall":"Bronze",
            "Fotos":[
                {
                    "id":51,
                    "Foto_Name":"Fundfoto"
                }
            ]
        }
    ]
} 

Relationale Datenbanken

Das relationale Datenmodell hat sich als Standard von Datenbankanwendungen etabliert, da sich damit die Realwelt mit recht einfachen und realitätsnahen Strukturen abbilden lässt. In der archäologischen Forschung wird dieses Datenmodell fast ausschließlich eingesetzt.

Vereinfacht kann man sich eine relationale Datenbank als eine Sammlung von Tabellen (Relationen) vorstellen, in denen jeder Datensatz in einer Zeile (Tupel) einer Tabelle gespeichert wird (untenstehende Abbildung). Jede Zeile besteht aus einer Anzahl von Attributen (Eigenschaften), den Spalten der Tabelle. Jedes Attribut hat einen eindeutigen zur Referenzierung dienenden Namen und einen bestimmten Attributtyp, welcher definiert welche Art von Daten - beispielsweise Zeichens√§tze (String) oder Flie√ükommazahlen (Float) - in dem Attribut gespeichert werden k√∂nnen. Jedes Attribut kann Werte entsprechend ihres Wertebereiches aufnehmen, der sich aus den Attributtyp ergibt. Zum Beispiel kann eine M√ľnze mit Hilfe folgender Attribute (mitsamt Attributtypen) beschrieben werden: ID (Integer), Nominal (String), Datierung (String), Material (String), Durchmesser (Integer), Gewicht (Float), Funddatum (Date).

datenbanken_relationBsp.png

Aufbau der Relation "M√ľnze" am Beispiel von Informationen zu M√ľnzen.
Aufbau der Relation "M√ľnze" am Beispiel von Informationen zu M√ľnzen.

Pro Tabelle werden immer nur gleichartige, reale Objekte (Entit√§ten) erfasst, z. B. nur Befunde, nur M√ľnzen, nur Fotos, nur Bauwerke etc. Die eindeutige Referenzierung eines Datensatzes erfolgt mit Hilfe eines oder mehrer Schl√ľsselattribute, dem sogenannten Prim√§rschl√ľssel. Dieser Schl√ľssel ist einzigartig und darf sich niemals √§ndern, da damit die Zeile in der Tabelle referenziert wird. Der Aufbau aller Tabellen, die zu einer Datenbank geh√∂ren, also die Datenbankstruktur, muss in dem Datenkatalog dokumentiert werden. Dieser enth√§lt somit alle Festlegungen und Detailinformationen, die die Struktur der Datenbankinhalte in einem konkreten DBMS beschreiben, z.B. den Typ verschiedener Attribute (Kurztext, Langtext, Zahlen, Datum, Medien, etc.) und die Abh√§ngigkeiten der Attribute zueinander. Der wichtigste Teilaspekt des Datenkataloges ist das Datenbankschema, das in abstrahierter Form die Beziehung und Art der Speicherung von Einzelinformationen festlegt.

Beziehungen

Einzelne Tabellen k√∂nnen anhand von Schl√ľsseln miteinander in Beziehung gesetzt werden, um Beziehungen zwischen einzelnen Datens√§tzen aus den unterschiedlichen Tabellen explizit auszudr√ľcken. Beispielsweise um einer M√ľnze, welche in der Tabelle "M√ľnze" gespeichert ist, einem Fundort, welcher in der Tabelle "Fundort" gespeichert ist, zuzuweisen (untenstehende Abbildung). Mit Hilfe von Prim√§rschl√ľsseln (Hauptschl√ľssel, engl. Primary Key) wird der Datensatz einer Relation eindeutig definiert, wie im vorliegenden Beispiel mit Hilfe des Attributs "Muenze-ID". Der Prim√§rschl√ľssel einer Relation darf dabei nur einmal vorkommen, muss also einzigartig sein, um eine Referenzierung zu gew√§hrleisten.

Ein Fremdschl√ľssel (engl. Foreign Key) dient zur Referenzierung eines Prim√§rschl√ľssels einer anderen Tabelle. In dem M√ľnzenbeispiel wurde die Relation "Muenze" um eine Attribut "FS_FundortID" erweitert. Es ist ein Fremdschl√ľssel, welcher auf den Prim√§rschl√ľssel "PS_FundortID" der Relation Fundort verweist.

datenbanken_beziehungBsp.png

Beispielhafte Beziehung zwischen der Relation "Muenze" und der Relation "Fundort".
Beispielhafte Beziehung zwischen der Relation "Muenze" und der Relation "Fundort".

Die Beziehungen zwischen zwei verschiedenen Relationen können dabei mit den folgenden gebräuchlichen Beziehungstypen beschrieben werden. Der Beziehungstyp wird dabei mit Hilfe einer Mengenangabe, der Kardinalität, angesprochen, der angibt wie viele Datensätze einer Relation mit wie vielen Datensätzen einer weiteren Relation in Beziehung stehen:

  • In 1 : 1 - Beziehungen ist jedem Datensatz einer Tabelle A nur ein einziger passender Datensatz in Tabelle B zugeordnet. Diesen Beziehungstyp verwendet man unter anderem, um eine un√ľbersichtliche Tabelle mit vielen Attributen in mehrere √ľbersichtliche Tabellen aufzuteilen. Beispielsweise werden in einer Tabelle f√ľr M√ľnzen allgemeine Eigenschaften abgebildet und die Einzelheiten f√ľr die Vorder- und R√ľckseite einer M√ľnze werden in gesonderten verkn√ľpften Tabellen beschrieben.
  • In 1 : N - Beziehungen, k√∂nnen einem Datensatz der Tabelle A mehrere passende Datens√§tze aus Tabelle B zugeordnet sein, wobei jedoch einem Datensatz aus Tabelle B nie mehr als ein Datensatz aus Tabelle A zugeordnet werden kann. Beispielsweise k√∂nnen an einem Fundort mehrere M√ľnzen gefunden worden sein, aber eine M√ľnze kann nur einen Fundort haben, wie in der Abbildung oben dargestellt ist.
  • Bei M : N - Beziehungen k√∂nnen jedem Datensatz aus einer Tabelle A mehrere passende Datens√§tze aus einer Tabelle B zugeordnet sein und umgekehrt. Auf einem Foto k√∂nnen beispielsweises mehrere M√ľnzen zu sehen sein, w√§hrend es f√ľr eine M√ľnze auch mehrere Fotoansichten geben kann.

Attributtypen

Es gibt verschiedene Attributtypen, die spezifische Informationen und Wertebereiche speichern:

  • Ganze Zahlen (integer, long) sind zu verwenden f√ľr Schl√ľssel, ordinalskalierte Variablen, wie etwa Schulnoten, oder sonstige numerische Angaben, bei denen die Genauigkeit ganzer Zahlen ausreichend ist.
  • Flie√ükommazahlen (float) kommen zum Beispiel bei metrischen Ma√üen zum Einsatz. Bei allen Ma√üeinheiten ist zu beachten, dass in der Attributdefinition die verwendete Ma√üeinheit notiert und diese w√§hrend der Benutzung auch einheitlich verwendet wird.
  • Bool'sche Felder lassen nur zwei Werte zu: "ja" (1) oder "nein" (0) bzw. "wahr" oder "falsch".
  • Textfelder (varchar) k√∂nnen mit einer maximalen L√§nge definiert werden oder aber ohne weitere Angaben standardm√§√üig bis maximal 255 Zeichen verwendet werden.
  • Gr√∂√üere Textfelder (text) erlauben einen beliebig langen Freitexteintrag. Sie sollten so wenig wie m√∂glich verwendet werden, da sie verhindern Informationen strukturiert einzutragen und somit ein gezieltes Auffinden erschweren. Sie k√∂nnen bei einer sp√§teren Konvertierung einer DB in ein neues System Schwierigkeiten verursachen.
  • Medienfelder/Binary Large Objects (BLOBs) ist ein bin√§rer Datentyp, der zur datenbankinternen Speicherung von externen Medieninhalten (Fotos, Zeichnungen, Filme, Texte etc.) verwendet werden kann. Jedoch empfiehlt es sich diese Medieninhalte au√üerhalb der eigentlichen Datenbank zu speichern und nur die Referenz auf den Speicherort der externen Ressource in einem Attribut zu erfassen. Dadurch werden u. a. die Datenbankgr√∂√üe √ľberschaubar gehalten, eine konsistente Datenhaltung der Einzeldaten gew√§hrleistet und Probleme beim Export der Datenbankinhalte reduziert. Ist im Ausnahmefall dennoch das Importieren von externen Medieninhalten notwendig, sollten diese f√ľr den jeweiligen Zweck optimiert sein (z. B. sind f√ľr die Bildvorschau geringe Bildaufl√∂sungen ausreichend).

Structured Query Language (SQL)

Mit Hilfe von speziellen Datenbanksprachen kann ein Benutzer oder ein externes Programm √ľber das DMBS mit einer Datenbank kommunizieren. Die am weitesten verbreitete Datenbanksprache im Bereich der relationalen Datenbanken ist SQL (structured query language). Sie wird rechnerunabh√§ngig und produkt√ľbergreifend seit 1986 im ISO Standard 9075 definiert. Seitdem erfuhr SQL sieben Erweiterungen, von denen die letzte Aktualisierung 2011 als ISO/IEC 9075:2011 erschienen ist.

SQL-Befehle lassen sich in vier verschiedene Befehlsgruppen unterteilen:

Befehlsgruppe Beschreibung Beispiel
Data Definition Language (DDL) Befehle zur Definition des Datenbankschemas: Erstellen von Datenbanken, Tabellen und Indizes. /* Anlegen der Tabelle 'muenzen' mit beispielhaften Attributen unter Angabe des Datentyps */
        CREATE TABLE muenzen
        (PS_MuenzID serial NOT NULL,
            Nominal varchar,
            Gewicht float);
Data Query Language (DQL) Befehle zum Abfragen von Daten. /* Abfrage nach allen M√ľnzen mit Fundort Paris. */
        SELECT *
        FROM muenzen
        WHERE FS_FundortID = '1'
Data Manipulation Language (DML) Befehle zur Datenmanipulation, also dem √Ąndern, Bearbeiten und L√∂schen von Datens√§tzen. /* √Ąndern des Materials in Gold f√ľr den dritten Datensatz */
        UPDATE muenzen
        SET Material = 'Gold'
        WHERE  PS_MuenzID = '3'
Data Control Language (DCL) Befehle zum Anlegen von Benutzern und zur Definition von Zugriffsrechten -- Nutzers mit Passwort anlegen
        CREATE USER mmustermann
        PASSWORD 'passwort'

Entity-Relationship-Modell (ERM)

Ein wichtiges grafisches Hilfsmittel beim Entwurf und zur Dokumentation einer Datenbank ist das Entity-Relationship-Modell (ERM). Neben der grafischen Visualisierung mittels eines Entity-Relationship-Diagram (ERD) ist auch die tabellarische Erfassung und Beschreibung aller Entit√§tstypen, Beziehungstypen und Attribute f√ľr eine vollst√§ndige Dokumentation einer Datenbank notwendig. Das ERD ist ein beschriftetes Diagramm mit festgelegten Symbolen, das dazu dient, den gew√ľnschten Ausschnitt der realen Welt formal zu beschreiben. Grundlage der ER-Modelle ist die Abstraktion von Objekten und deren Beziehungen untereinander. Folgende grundlegende Begriffe in einem ERM und deren grafische Wiedergabe in einem ERD werden in diesem Zusammenhang unterschieden:

Element Beschreibung Grafische Darstellung
Entit√§t (Datensatz) Objekt der Wirklichkeit, materiell oder abstrakt, z. B. ein Fund "M√ľnze XY", ein Befund "Pfostenloch 123" oder eine Abteilung "DAI Rom". keine grafische Darstellung
Entitätstyp (Tabelle) Abstraktion gleichartiger Entitäten, z. B. Personen, Funde, Befunde, Adressen.
Beziehung semantische Beziehung zwischen verschiedenen Datens√§tzen aus unterschiedlichen Tabellen, z. B. "M√ľnze" in "Pfostenloch"
Beziehungstyp Abstraktion gleichartiger Beziehungen, z. B. "gefunden in".
Kardinalit√§t m√∂gliche Anzahl der an einer Beziehung beteiligten Entit√§ten (s. u. Beziehungsarten); Symbol: 1, N oder M √ľber Strich
Attribut Eigenschaften eines Entitätstyps oder eines Beziehungstyps, z. B. Geburtsdatum von Personen.
Schl√ľssel Attribut/e, welche/s zur eindeutigen Identifizierung einer Entit√§t von einem Entit√§tstypen dient/en.

Bestandteile einer Datenbank

Um eine Datenbank auch zuk√ľnftig nutzen und die in ihr erfassten Inhalte verstehen zu k√∂nnen, ist eine umfassende und vollst√§ndige Dokumentation erforderlich, zu der verschiedene Komponenten geh√∂ren:

  • Die schriftliche und/oder tabellarische Anforderungsanalyse
  • Die eigentlichen Datenbankinhalte
  • Die Beschreibung der Datenstruktur
  • Die Definition der implementierten Funktionalit√§ten
  • Semantisch-inhaltliche Aspekte wir vorgegebene Wertelisten, Thesauri oder individuelle Definitionen von Begriffen und Datens√§tzen
  • Dokumentation der grafischen Benutzeroberfl√§chen und verschiedenen Sichten auf die Daten (z.B. Eingabeformulare, Suchmasken, Ausgabeformate), technischen Schnittstellen und¬† erstellten Regelwerke (z.B. Benutzerhandb√ľcher)

Da mit keinem der empfohlenen Dateiformate alle Komponeneten erfasst und archiviert werden können, ist eine hybride Archivierungsstrategie erforderlich. Beispielsweise können der Inhalt, die Struktur und die Funktionalitäten einer Datenbank im SIARD-Format archiviert werden. Die Anforderungen werden schriftlich beschrieben und um ein grafisches Enitity-Relationship-Diagramm ergänzt. Individuelle Vorgaben zur Benutzung (insbesondere der Dateneingabe) werden mittels eines Benutzerhandbuches im Format PDF/A dokumentiert und die einzelnen Layoutmasken werden mittels Screenshots als unkomprimierte TIFF-Dateien gespeichert.

Die folgenden Tabelle gibt einen √úberblick √ľber die verschiedenen Formate f√ľr Datenbanken und welche davon f√ľr die langfristige Speicherung der genannten Dokumentationskomponenten¬† von Datenbanken geeignet sind.

Formate f√ľr Datenbanken und welche Elemente sie langfristig Speichern k√∂nnen. I = Datenbankinhalt, S =Datenbankstruktur, F = Funktionalit√§ten, B = Benutzung. Leere Zellen bedeuten fehlende Speichereigenschaften.

Format, Dokument I S F B
SIARD ‚úď ‚úď ‚úď ¬†
SQL ‚úď ‚úď ‚úď ¬†
XML ‚úď (‚úď) ¬† ¬†
CSV ‚úď ¬† ¬† ¬†
JSON ‚úď ¬† ¬† ¬†
ERD (z. B. TIFF) ¬† ¬† ‚úď ¬†
Benutzerhandbuch (z. B. PDF/A) ¬† ¬† ¬† ‚úď
beschriebene Bildschirmfotos (z. B. TIFF) ¬† ¬† ¬† (‚úď)
MDB, ACCDB        
FP5, FP7, FMP12        
ODB ¬† ¬† ¬† (‚úď)
DMP, BAK, DB        

 

Letzte Änderung: 7. August 2017