4 Datenhaltung

Big Data: Volume, Variety (unterschiedliche Datentypen), Velocity

Datenbanksystem DBS besteht aus …

·       Datenbankmanagementsystem DBMS: speichern, pflegen, verarbeiten von Daten

·       Datenbanken: enthalten verfügbare Daten in geordneter Form

Schnittstelle zwischen DBS und Terminal für den Benutzer: Datenbanksprache

Ziele des DMBS:

·       Datenunabhängigkeit: Änderung hinsichtlich der Speicherung der Daten soll keinen Einfluss auf Anwender haben

·       Datenintegrität: Korrektheit der gespeicherten Daten hinsichtlich ihres Datentyps

·       Effiziente Anfragebearbeitung: Daten, die bestimmte Anfragebedingungen erfüllen, sind auffindbar ohne gesamte Datenbank zu durchsuchen

·       Gesicherter Mehrbenutzerbetrieb: Parallele Zugriffe auf eine Datenbank führt zu keinen Konflikten/ Widersprüchen

• Zentrales DBS (Datenbanksystem):

  • Pro:

    • Bessere Möglichkeiten des Datenschutzes

    • Vereinfachte Administration

  • Con:

    • Single Point of Failure

    • Möglicherweise inakzeptable Kommunikationsleistung oder Verfügbarkeit

• Verteiltes DBS (Datenbanksystem):

  • Pro:

    • Relevante Daten können anwendernäher gespeichert werden

    • Bessere Verteilung der Anfragen über das gesamte System

  • Con:

    • Redundante Datenspeicherung

    • Komplexere Planung, Implementierung und Wartung

·       SQL als einheitliche Datenbanksprache; Speicherung aller Daten in Form von Tabellen

·       Optimiert auf zentrale Datenhaltungsstrategie

·       Garantierte Konsistenzerhaltung

NoSQL Datenbanken: Not only SQL

·       Keine einheitliche Datenbanksprache

·       Optimiert auf verteilte Datenhaltungsstrategien

·       Konsistenz nur verzögert gewährleistet

·       Bestehen aus Graphen, welche durch Kanten miteinander in Beziehung stehen

·       Unterscheidung zwischen gewichteten und ungewichteten Graphen sowie hierarchische- und Netzwerk-Modelle

·       Pro: Verarbeitung dynamischer Informationen, flexible + agile Strukturen (gut erweiterbar), Entdecken neuer, unbekannter Strukturen

·       Con: Ein-Server-Architektur (schlechte Skalierbarkeit), keine einheitliche Abfragesprache, ineffizient bei sich oft wiederholenden Abfragen

·       Anwendungsbeispiele: soziale Netze, Bild- und Textanalyse, Materialflussoptimierung

·       Unstrukturierte Daten werden mithilfe von Datenformaten wie JSON order XML gespeichert

·       Eigenschaften werden als Key/Value-Paare definiert, können entsprechend abgefragt werden

·       Pro: Verarbeitung unstrukturierter Daten, flexible Strukturierung der Informationen (schemalos), schnelle/einfache Informationsübermittlung

·       Con: Unterstützung vernetzter Daten, erhöhter Aufwand der Abfrageprogrammierung

·       Anwendungsbeispiele: Web 2.0, Robotik

·       Führende Systeme: CouchDB, MonoDB

·       Datensätze werden mit Attributen/Methoden in einem Objekt gekapselt -> alle Informationen über Objektanfrage abrufbar

·       Eindeutige Objektunterscheidung durch systemseitig zugewiesenen eindeutigen Objektidentifikator (OID)

·       Vererbungshierarchie: grob unterschiedliche Objekte in Klassen aufteilen

·       Pro: Kapselung, Objektidentität, Vererbungshierarchie, Verarbeitung komplexer Daten

·       Con: Plattformabhängigkeit, wenig verbreitet, kein einheitlicher Standard

·       Anwendungsbeispiele: Telekommunikation, Fertigungsanwendungen, Geoinformationssysteme, Multimedia

·       Daten werden auf verschiedene Relationen aufgeteilt, durch Schlüsseleigenschaften verknüpft

·       Tupel = Zelle mit semantisch zusammengehörenden Werten

·       Verwendung Normalformen (Partitionieren einer Relation nach bestimmten Regeln)  Redundanzfreiheit + Konsistenz

·       Pro: einfaches Datenmodell, Datenkonsistenz, geringe Redundanz, einheitliche Abfrage Sprache (SQL), Verbreitung, Zuverlässigkeit

·       Con: starre Struktur (geringe Skalierbarkeit), komplexe Daten tabellarisch nicht abbildbar, keine Hierarchie/Objektidentität, schlechte Performance durch Partitionierung

·       Anwendungsbeispiele: große + einfach strukturierte Datenbestände, Personaldaten, Geschäftsdaten, einfache Produktionsdaten

·       Objekte können in Tabellen gespeichert werden

·       Automatische Erzeugung eines OID, der für Datenabfrage Objekt bzw. Tupel referenziert

·       Übersetzung von Tabellen in Objekte erfolgt nach 3 Spezialisierungshierarchien

·       Neue Basisdaten ermöglichen Verarbeitung komplexer Datentypen

·       Pro: vereint Vorteile von RDB& ODB, Hierarchie, Objektidentität darstellbar, Unabhängigkeit von Abfragesprache

·       Con: Normalformen nicht anwendbar, hohe funktionale Komplexität

·       Anwendungsbeispiele: moderne Anwendungssysteme, Bilder- & Audiodateien, ORDBMS

1.     Definition von Bewertungskriterien: Netzwerkfähigkeit, Datensicherheit, Flexibilität, Herstellerunterstützung, …

2.     Definition von Datenbanken, die Must-Have-Kriterien erfüllen

3.     Festlegen von Gewichtungsfaktoren

4.     Bewertung des Erfüllungsgrades

5.     Auswahl der bestbewertesten Datenbank