Wirtschaftsinformatik Wiki - Kewee

Benutzer-Werkzeuge

Webseiten-Werkzeuge

Zuletzt angesehen:
bigdata:dokumentdb

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen RevisionVorhergehende Überarbeitung
Nächste Überarbeitung		Vorhergehende Überarbeitung
Nächste ÜberarbeitungBeide Seiten der Revision
bigdata:dokumentdb [2015/10/05 19:41] – [Verwendung] brueckbigdata:dokumentdb [2015/10/05 21:18] – [Dokumentenorientierte Datenbanken] brueck
Zeile 1: Zeile 1:
 ====== Dokumentenorientierte Datenbanken ====== ====== Dokumentenorientierte Datenbanken ======
  
-**Dokumentenorientierte Datenbanken** (oder auch **dokumenten//basierte// Datenbanken**) speichern Daten in Form von Key-Value-Paaren. Wobei zu jedem Schlüssel ein Wert, bzw. **Dokument**. Ein Dokument meint dabei eine Aggregation mehr oder weniger strukturierter Daten ohne Schemavorgabe ([[bigdata:literatur|Pürner 2013]]).+**Dokumentenorientierte Datenbanken** (oder auch **dokumenten//basierte// Datenbanken**) speichern Daten in Form von Key-Value-Paaren. Wobei zu jedem Schlüssel ein Wert, bzw. **Dokument**. Ein Dokument meint dabei eine Aggregation mehr oder weniger strukturierter Daten ohne Schemavorgabe ([[bigdata:literatur#p|Pürner 2013]]).
  
  
Zeile 13: Zeile 13:
 Zwar ist keinerlei Struktur vorgeschrieben und tatsächlich kann jedes Dokument vollkommen anders aufgebaut sein, doch in der Regel wird man nicht wahllos Felder anlegen, sondern dabei ein gewisses, der Anwendung entsprechendes (indirektes) Schema verfolgen, um im Nachhinein auch eine Voraussetzung für sinnvolle Abfragen zu schaffen. So würde man bei einem Shop instinktiv davon ausgehen, dass in einem Dokument für eine Bestellung sowohl ein Feld „Preis“, als auch ein Feld „Anzahl“ mit den entsprechenden Werten und Datentypen dahinter vorhanden ist (und das jene Felder auch genau so heißen und nicht etwa „Kostenpunkt“ und „Menge“). Nichtsdestotrotz ließe sich ein solches Bestellungs-Dokument z.B. ohne weiteres um ein Feld „Anmerkungen“ erweitern. Sollte es zu einer Abfrage kommen, bei der dieses Feld eine Rolle spielt, würden auch nur die Dokumente berücksichtigt, die auch über ein solches Feld verfügen. Bei einer relationalen Datenbank hätte man diese Flexibilität nicht. Dieses Feld müsste auf jeden Fall für alle Bestellung existieren. Zwar ist keinerlei Struktur vorgeschrieben und tatsächlich kann jedes Dokument vollkommen anders aufgebaut sein, doch in der Regel wird man nicht wahllos Felder anlegen, sondern dabei ein gewisses, der Anwendung entsprechendes (indirektes) Schema verfolgen, um im Nachhinein auch eine Voraussetzung für sinnvolle Abfragen zu schaffen. So würde man bei einem Shop instinktiv davon ausgehen, dass in einem Dokument für eine Bestellung sowohl ein Feld „Preis“, als auch ein Feld „Anzahl“ mit den entsprechenden Werten und Datentypen dahinter vorhanden ist (und das jene Felder auch genau so heißen und nicht etwa „Kostenpunkt“ und „Menge“). Nichtsdestotrotz ließe sich ein solches Bestellungs-Dokument z.B. ohne weiteres um ein Feld „Anmerkungen“ erweitern. Sollte es zu einer Abfrage kommen, bei der dieses Feld eine Rolle spielt, würden auch nur die Dokumente berücksichtigt, die auch über ein solches Feld verfügen. Bei einer relationalen Datenbank hätte man diese Flexibilität nicht. Dieses Feld müsste auf jeden Fall für alle Bestellung existieren.
  
 +{{ :bigdata:documentstore.png |}}
 +(Grafik-Quelle: [[bigdata:literatur|Couchbase o. J.]])
  
 ===== Vorteile ===== ===== Vorteile =====
bigdata/dokumentdb.txt · Zuletzt geändert: 2015/10/05 21:19 von brueck