Datenbank SpektrumDOI 10.1007/s13222-014-0156-z

S C HWE R PU N KTB E ITRAG

Datenbanken ohne Schema?Herausforderungen und Lösungs-Strategien in der agilen Anwendungsentwicklung mitschema-flexiblen NoSQL-Datenbanksystemen

Meike Klettke · Stefanie Scherzinger · Uta Störl

Eingegangen: 3. Februar 2014 / Angenommen: 28. April 2014© Springer-Verlag Berlin Heidelberg 2014

Zusammenfassung In der Entwicklung von interaktivenWeb-Anwendungen sind NoSQL-Datenbanksysteme zuneh-mend beliebt, nicht zuletzt, weil sie flexible Datenmodelleerlauben. Das erleichtert insbesondere ein agiles Projektma-nagement, das sich durch häufige Releases und entsprechendhäufige Änderungen am Datenmodell auszeichnet. In diesemArtikel geben wir einen Überblick über die besonderen Her-ausforderungen der agilen Anwendungsentwicklung gegenschemalose NoSQL-Datenbanksysteme. Wir stellen Strate-gien für die Schema-Evolution aus der Praxis vor, und po-stulieren unsere Vision einer eigenen Schema-Management-Komponente für NoSQL-Datenbanksysteme, die für einekontinuierliche und systematische Schema-Evolution aus-gelegt ist.

Schlüsselwörter NoSQL-Datenbanksysteme ·Schema-Informationen · Schema-Evolution

1 Einführung

Die klassische Datenbankvorlesung lehrt Schema-Entwurfals top-downAnsatz, ausgehend von einer umfassenden, vor-ausschauenden Modellierung der Anwendungsdomäne hinzur Definition der einzelnen Relationen. In vielen Anwen-

M. Klettke (�)Universität Rostock, Rostock, DeutschlandE-Mail: meike.klettke@uni-rostock.de

S. ScherzingerOTH Regensburg, Regensburg, DeutschlandE-Mail: stefanie.scherzinger@oth-regensburg.de

U. StörlHochschule Darmstadt, Darmstadt, DeutschlandE-Mail: uta.stoerl@h-da.de

dungsbereichen, wie etwa bei der Entwicklung von Web-Anwendungen, wird hingegen zunehmend agil vorgegangen.Releases im wöchentlichen, wenn nicht gar täglichen Rhyth-mus sind üblich. „Ship early and often“ ist nicht nur das Man-tra der kleinen Startups, sondern auch das Vorgehensmodellder Internet-Giganten wie Google oder Facebook. Diese Be-schleunigung in der Anwendungsentwicklung wirkt sich un-weigerlich auf das Schema der Datenbank aus. In vielen Pro-jekten ist es somit nicht mehr möglich, vorab ein fixes Sche-ma zu definieren, das über mehrere Releases stabil bleibt.Gleichzeitig sträuben sich agile Entwickler zunehmend, aufdas nächste Wartungsfenster des Datenbankadministratorszu warten, um ihre Schema-Änderungen integrieren zu kön-nen. In Entwicklerkreisen spricht man statt dessen von „agi-len Datenbanken“, und meint damit Strategien, das Daten-bankschema gemeinsam mit der Anwendungslogik iterativvoranzutreiben (z. B. [1]). Mit Google’s F1 [2] gibt es zu-dem ein neues System mit relationalem Charakter, das eigeneProtokolle verwendet, um tägliche Schema-Änderungen ineinem verteilten System zu propagieren.

Eine Alternative besteht darin, auf schemalose Daten-banksysteme umzusteigen. Viele NoSQL-Systeme arbeitenohne festes Schema (z. B. [3–6]). Die persistenten Objektekönnen dabei für die Anfrageauswertung indiziert werden,selbst wenn die Objekte unterschiedlich strukturiert sind.So wird die Anwendungsentwicklung nicht durch ein fixesSchema eingeschränkt.

Eine Besonderheit im Web-Umfeld ist, dass die Anwen-dung verfügbar bleiben muss, auch wenn Schema-Änder-ungen umzusetzen sind. In der Anwendungsentwicklungmit NoSQL-Datenbanksystemen haben sich dazu in denletzten Jahren verschiedene Strategien zum Umgang mitSchema-Evolution bewährt.

M. Klettke et al.

(a) UML-Modell einer Quiz-Frage.

{"entity_type" : "Frage","id" : 4711,"text" : "Welche Schrift ist eine Serifenschrift?","antworten" : [{"text" : "Helvetica", "ist_richtig" : false},{"text" : "Calibri", "ist_richtig" : false},{"text" : "Times New Roman", "ist_richtig" : true},{"text" : "Arial Black", "ist_richtig" : false} ],

"anzahl_maengel" : 0}

(b) Eine Quiz-Frage im JSON-Format.

Abb. 1 Jede Quiz-Frage der ersten Version hat vier mögliche Antwor-ten. Zudem werden die Bemängelungen gezählt

Wir stellen diese Strategien an einem kleinen Beispielvor. Interaktive Quiz-Spiele nach dem Vorbild von TrivialPursuit sind derzeit sehr beliebt. Als Anbieter eines solchenSpiels veröffentlichen wir früh die erste Version, um in denMarkt einzusteigen.Abbildung 1a zeigt das UML-Modell ei-ner Quiz-Frage.1 Jede Frage hat eine eindeutige id, einen Textund vier mögliche Antworten. Nur eine Antwort ist richtig.Die Spieler können Fragen bemängeln, etwa weil Sachfehlervorliegen. Dabei wird die Anzahl der Mängel erfasst.

Abbildung 1b zeigt eine Frage im JSON-Format. Diemöglichen Antworten sind als verschachtelte Attribute rea-lisiert. Für die repetitive Übersetzung einzelner JSON-Dokumente in Objekte derAnwendungslogik werden ObjectMapper Bibliotheken benutzt (z. B. [7–9]). Die Annotation@Entity dient dem Object Mapper als Hinweis, dass Fragen-Objekte persistiert werden. Die Annotation @Id deklariertdas Schlüsselattribut.

Im nächsten Release wollen wir Mängel besser unter-scheiden können – handelt es sich um Sachfehler, Recht-schreibfehler oder um zweifelhaften Inhalt? Abbildung 2azeigt das neue Datenmodell. Das JSON Dokument inAbb. 2bhat die neue Struktur.

Nun steht das Entwicklungsteam vor einer Herausfor-derung, denn das NoSQL-Produktivsystem enthält bereitsQuiz-Fragen der alten Struktur. Im Folgenden betrachtenwir grundlegende Strategien, die in der Praxis gängig sind.In Abb. 3 visualisieren wir die Ansätze schematisch. Zeit-punkt t0 markiert den ersten Release. Die Anzahl der Fragenim Fragenkatalog nach dem Modell von Abb. 1 wächst stän-

1 Die UML Modelle wurden mit http://yuml.me/erstellt.

(a) Erweitertes UML-Modell einer Quiz-Frage.

{"entity_type" : "Frage","id" : 4712,"text" : "Wie heisst ein Buch von Jostein Gaarder?","antworten" : [

{"text" : "Sofies Welten","ist_richtig" : true}, ... ],

"maengel" : [{"art" : "SACHMANGEL","freitext" : "Das Buch heisst ’Sofies Welt’!"},

{"art" : "SACHMANGEL","freitext" : "Alle Antworten sind falsch."}]}

(b) Ausschnitt einer Quiz-Frage im JSON-Format.

Abb. 2 Bei Quiz-Fragen der zweiten Version werden Mängel genaueraufgeschlüsselt

dig. Zum Zeitpunkt t1 wird der zweite Release veröffentlicht.Fragen haben nun die neue Struktur aus Abb. 2.

Versionen-Pluralismus: Abbildung 3a zeigt einen plurali-stischen Ansatz, wonach beide Versionen von Fragen in derDatenbasis koexistieren. Ab Zeitpunkt t1 haben alle neu an-gelegten Fragen die neue Struktur. Entsprechend muss dieAnwendungslogik mit Datensätzen beider Versionen arbei-ten können, was die Anwendungsentwicklung und Quali-tätssicherung erheblich erschwert. Betrachten wir dazu un-ser Beispielszenario. Als Betreiber des Online-Spiels wollenwir umstrittene Fragen inspizieren. Dazu wird eine Anfragein JPQL2 gestellt, die versionsübergreifend formuliert ist.

select f.id, f.text from Frage fwhere f.anzahl_maengel > 100

unionselect f.id, f.text from Frage fwhere size(f.maengel) > 100

Eager Migration: Alternativ können alle existierendenDatensätze migriert werden. Der Effekt einer eagerMigration wird in Abb. 3b veranschaulicht. Zum Release-zeitpunkt t1 sind alle vorhandenen Fragen zu aktualisieren.

2 Die Java Persistence Query Language ist die Anfragesprache inner-halb der Java Persistence API für Java-Entitäten [10]. JPQL hat eineSQL-ähnliche Syntax.

Datenbanken ohne Schema?

(a) Beim Versionenpluralismus bleibenexistierende Datensätze unverandert.

(b) Im eager Ansatz werden alle exis-tierenden Datensätze migriert.

(c) Im lazy Ansatz werden existierendeDatensatze nur bei Bedarf migriert.(c) Im lazy Ansatz werden existierende

Abb. 3 Zeitliche Entwicklung der Anzahl der Datensätze in der alten Version ab Zeitpunkt t0 (Schraffur mit Linien) und in der neuen Version abZeitpunkt t1 (Schraffur mit Punkten) in der NoSQL-Datenbank

Während der Migration muss der Anwendungsbetrieb auf-recht erhalten werden. Viele Platform-as-a-Service Anbietererlauben es, mehrere Versionen einer Anwendung parallelzu betreiben. Sofern es gelingt, die Datensätze jeweils ex-klusiv einer Version der Anwendung zuzuordnen, kann derAnwendungsbetrieb unterbrechungsfrei fortgeführt werden.Während der Migration kommen laufend neue Fragen hinzu.Nach Abschluss der Migration sind alle Fragen in der aktuel-len Version. Eine eager Migration erleichtert langfristig dieWartung derAnwendung. Um in unserem Beispiel wieder dieumstrittenen Fragen zu finden, genügt ab Zeitpunkt t1 + Δ

eine Anfrage gegen das neue Schema:

select f.id, f.text from Frage fwhere size(f.maengel) > 100

Eine eager Migration verursacht allerdings unnötige Kosten,wenn nicht alle Daten künftig auch gebraucht werden: Wirddie NoSQL-Datenbank als Database-as-a-Service genutzt,werden sämtliche Schreib- und Leseoperationen in Rech-nung gestellt.

Üblicherweise unterstützen schemalose NoSQL-Produkte keine systematische eager Migration. StrukturelleUpdates finden oft nur auf einzelnen Datensätzen statt. Es istalso den Anwendungsentwicklern überlassen, die nötigenMigrationsskripte zu schreiben.

Lazy Migration: Ein etablierter Ansatz mit einem fließen-deren Übergang zwischen Versionen ist eine lazy Migration,wie sie bereits in einigen Object Mappern implementiert wird(z. B. [7, 8]). Hier werden Datensätze beim Laden in die An-wendung migriert. Abbildung 4 zeigt einen solchen ObjectMapper für Quiz-Fragen der Version 2, der auch alte Quiz-Fragen laden kann. Die Annotation @IgnoreSave deklariert,dass das Attribut anzahl_maengel zwar geladen wird, aber

Abb. 4 Klasse mit Annotationen für eine lazy Migration

beim Schreiben nicht persistiert wird. Die Funktion mit derAnnotation @OnLoad wird bei jedem Laden eines Datensat-zes ausgeführt. Sofern der Datensatz noch die alte Strukturhat, wird er ad-hoc migriert. Diese Aktualisierung wird dannbeim nächsten Persistieren des Datensatzes in der NoSQL-Datenbank festgeschrieben.

Abbildung 3c skizziert den zeitlichen Verlauf. Mit Relea-se von Version 2 haben die neu hinzugefügten Quiz-Fragendie neue Struktur. Existierende Fragen werden durch den Ob-ject Mapper beim Laden in die Anwendung auf die aktuelleVersion migriert. Datensätze, auf die nicht mehr zugegriffenwird, bleiben in der ursprünglichen Version. Daten werdennicht unnötig migriert, und ein unterbrechungsfreier Betriebder Anwendung ist möglich. Allerdings wird der Migrati-onscode im Object Mapper schnell unübersichtlich, wennmehrere Altversionen zu unterstützen sind. Zudem müssenbei der Formulierung von Anfragen weiterhin alle Versionenvon Fragen berücksichtigt werden.

M. Klettke et al.

Hybride Ansätze: Langfristig ist es in der Anwendungsent-wicklung sinnvoll, einen hybriden Ansatz zu fahren, wonachkleine Änderungen im Schema lazy, Sprünge in der Evoluti-on hingegen eager umgesetzt werden. Kleinere Änderungenkönnen im operativen Betrieb auf den gerade verwendetenDatensätzen ausgeführt werden. Sind die Änderungen zu um-fassend oder haben sich zu viele Änderungen über die Zeitangesammelt, die nacheinander ausgeführt werden müssen,so empfiehlt sich hingegen eine eager Migration, in derenErgebnis alle Datensätze in der gleichen Version gespeichertsind.

Solange die systematische Unterstützung durch profes-sionelle Werkzeuge nicht gegeben ist, handelt es sich beidiesen Strategien um bloße Notbehelfe. Somit stellt sich dieFrage, wie Anwendungsentwickler von den Freiheiten sche-maloser Systeme langfristig profitieren können, ohne alsbalddie Kontrolle über ihre Datenbasis zu verlieren.

2 Desiderata an eineSchema-Management-Komponente fürNoSQL-Datenbanksysteme

In Abschn. 1 wurde erläutert, dass die Schemaflexibilität inNoSQL-Datenbanksystemen für viele Anwendungen wün-schenswert ist. Gleichzeitig gibt es etliche Szenarien, in de-nen eine Unterstützung für das Management der sich in kur-zen Abständen verändernden Datenstrukturen, also der sichverändernden (impliziten) Schemata, hilfreich wäre.

In diesem Abschnitt wird dargestellt, welche Desiderataeine Schema-Management-Komponente erfüllen muss. Wirskizzieren die Verwendung einer solchen Komponente sowieverschiedene Architekturansätze. Danach wird der Funkti-onsumfang einer Schema-Management-Komponente detail-liert erläutert.

Für welche Arten von NoSQL-Datenbanksystemen isteine solche Schema-Management-Komponente relevant?Die Systeme werden typischerweise nach dem verwende-ten Datenbankmodell klassifiziert [11]. Die drei wichtigstenArten sind dabei Key-Value-Datenbanksysteme, Dokumen-tenorientierte Datenbanksysteme sowie Column-Family-Datenbanksysteme.

Für Key-Value-Datenbanksysteme ist eine Schema-Management-Komponente weniger relevant, da die interneStruktur der gespeicherten Daten für das DBMS im Allge-meinen opak ist. Deshalb betrachten wir hier nur den Einsatzeiner solchen Komponente für Dokumentorientierte bzw.Column-Family-Datenbanksysteme.

Die in diesen beiden Arten von NoSQL-Datenbank-systemen gespeicherten Daten werden im Folgendenals Entities bezeichnet. Jedes Entity hat dabei eineeindeutige Id und eine Liste von Attributen. Attributekönnen, im Gegensatz zum relationalen Modell, nicht nur

skalar, sondern auch mehrwertig und ggf. geordnet sein.Ebenso ist es möglich, dass Attribute geschachtelt sind,was die Modellierung hierarchischer Strukturen ermöglicht.Jedes Entity gehört (implizit) zu einem Entity-Typ – dieexplizite Speicherung eines Entity-Typs wird bislang nurvon sehr wenigen NoSQL-DBMS unterstützt (siehe Abb. 7),kann aber durch die Einführung eines entsprechendenAttributs leicht realisiert werden.

Dieses abstrakte Modell gilt uneingeschränkt für Doku-mentorientierte Datenbanksysteme – für Column-Family-Datenbanksysteme gibt es einige Einschränkungen be-züglich der Abbildungsmöglichkeiten von mehrwertigenund hierarchischen Strukturen [12]. Dies stellt aber kei-ne Einschränkung für die Funktionalitäten einer Schema-Management-Komponente dar.

2.1 Desiderata

Eine Schema-Management-Komponente für NoSQL-Datenbanksysteme sollte idealerweise die folgendenFunktionalitäten anbieten:

• Definition eines Schemas• Validierung von Entities gegen ein Schema• Schema-Evolution inklusive

– Ausführung der zugehörigen Entity-Updates– Query Rewriting

Sofern nicht bereits seit Beginn der Entwicklung einer spe-zifischen Anwendung mit Schemata gearbeitet wird, ist esdarüber hinaus wünschenswert, aus bereits in der NoSQL-Datenbank gespeicherten Entities Schemata bzw. Schema-Versionen abzuleiten. In diesem Fall wird zusätzlich dieMöglichkeit zur

• Schema-Extraktion,

d. h. derAbleitung der Schemainformationen aus den gespei-cherten Entities benötigt.

2.2 Architekturvarianten

Es gibt verschiedene Architekturansätze, um eine Schema-Management-Komponente zu realisieren. Es ist sowohlmöglich, diese innerhalb eines NoSQL-DBMS zu imple-mentieren als auch als zusätzliche Schicht zwischen Anwen-dung und DBMS. Die Abb. 5 und 6 veranschaulichen diesebeiden Ansätze. Die verschiedenen Schema-Versionen wer-den in den Abbildungen durch Baumstrukturen symbolisiert,die Zugehörigkeit der Entities zu den jeweiligen Schema-Versionen durch die korrespondierenden Texturen.

Bei der Realisierung der Schema-Management-Komponente als zusätzliche Schicht (Abb. 6) kann dieSchemainformation entweder separat oder direkt innerhalb

Datenbanken ohne Schema?

Abb. 5 Schema-Management-Komponente innerhalb eines NoSQL-Datenbanksystems

des NoSQL-DBMS gespeichert werden. Diese Entschei-dung hängt u. a. davon ab, inwieweit das konkrete DBMSdie effiziente Speicherung der verwendeten Schemastruktu-ren unterstützt. Auf konkrete Realisierungsansätze wird inAbschn. 4.2 eingegangen.

Die Einführung einer Schema-Management-Komponentebedeutet nicht, dass diese von allen Anwendungen be-nutzt werden muss. Für jede Anwendung kann inidividu-ell entschieden werden, ob diese die Schema-Management-Komponente und ihre Funktionen benutzen soll oder nicht.Auch dies ist in den Abb. 5 bzw. 6 veranschaulicht.

2.3 Operationen

Ausgehend von den in Abschn. 2.1 geforderten Desideratawerden die folgenden Operationen innerhalb einer Schema-Management-Komponente benötigt:

Definition eines Schemas. Die Definition eines Schemasim NoSQL-Kontext bedeutet, dass die Struktur der Entity-Typen und ggf. zusätzliche Constraints für die Attributefestgelegt werden. Für jedes Attribut eines Entity-Typessollten die folgenden Eigenschaften definiert werdenkönnen:

Abb. 6 Schema-Management-Komponente als zusätzliche Schicht au-ßerhalb des NoSQL-Datenbanksystems

• Name• Struktur-Typ (atomar/mehrwertig/hierarchisch)• Constraint-Bedingungen (optional)

– existence constraint (not null)– primary key constraint– unique constraint– Wertebereich und weitere domain constraints

Für Beziehungen zwischen Attributen des gleichen oder ver-schiedener3 Entity-Typen werden darüber hinaus ggf. refe-rential integrity constraints benötigt.

Validierung von Entities gegen ein Schema. Ein Entitymuss beim Einfügen oder Ändern gegen das Schema bzw.die jeweils gültige Schema-Version validiert werden können.Dazu ist es natürlich vorab notwendig, Entities zu Schema-ta bzw. Schema-Versionen zuzuordnen. Hierfür muss in je-dem Entity der zugehörige Entity-Typ gespeichert werdenkönnen. Diese Möglichkeit wird derzeit nur von wenigenNoSQL-DBMS unterstützt (siehe Abb. 7), kann aber durch

3 Die Definition von Beziehungen zwischen verschiedenen Entity-Typen sollte aus Performance-Gründen im Kontext horizontal skalie-render NoSQL-Datenbanksysteme für große Datenmengen nur sehrwohlüberlegt eingesetzt werden [13].

M. Klettke et al.

die Einführung eines zusätzlichen Attributs leicht für jedesNoSQL-DBMS der betrachteten Kategorien realisiert wer-den. Das Gleiche gilt auch für die notwendige Unterstützungeiner Versionsnummer für jedes Entity, um die korrekte Zu-ordnung zu einer Schema-Version zu ermöglichen.

Schema-Evolution. Für eine Schema-Evolution werden diefolgenden Operationen benötigt:

• Hinzufügen eines neuen Entity-Typs• Löschen eines Entity-Typs• Umbenennen eines Entity-Typs• Update eines Entity-Typs

Die Update-Operation soll folgende Operationen für die At-tribute eines Entity-Typs bereitstellen:

• Hinzufügen eines Attributs• Löschen eines Attributs• Umbenennen eines Attributes• Verschieben einesAttributs von einem Entity-Typ in einen

anderen• Kopieren eines Attributs von einem Entity-Typ in einen

anderen

Eine Schema-Management-Komponente sollte die Migrati-on der existierenden Daten nach der Definition eines neu-en Schemas bzw. einer neuen Schema-Version unterstüt-zen. Dabei ist es wünschenswert, dass sowohl eager alsauch lazy Migration ausgeführt werden können. Wie in Ab-schn. 1 dargestellt, müssen bei lazy Migration Datenbank-abfragen verschiedene Versionen der Entities berücksich-tigen, was die Entwicklung der Datenbankabfragen kom-plex und fehleranfällig macht. Hier wäre es wünschens-wert, dass eine Schema-Management-Komponente aus denSchema-Evolutionsoperationen geeignete Query-Rewriting-Mechanismen ableitet. Das Umschreiben vonAnfragen unterConstraints ist im allgemeinen Fall unentscheidbar. Hier giltes, das Fragment derAnfragesprache und die Constraints ent-sprechend einzuschränken, um verwendbare Verfahren ent-wickeln zu können.

Schema-Extraktion. Wurde eine Anwendung zunächst oh-ne Verwendung einer Schema-Management-Komponenteentwickelt und soll sie zukünftig mit einer solchen Kompo-nente weiterentwickelt werden, muss das implizite Schemabzw. müssen die impliziten Schema-Versionen aus den be-reits persistierten Entities abgeleitet werden. Dieser Prozesswird als Schema-Extraktion bezeichnet.

3 Stand der Technik

In diesem Abschnitt wird analysiert, inwieweit NoSQL-Datenbanksysteme nativ bzw. mithilfe externer Schema-

Bibliotheken das Schema-Management unterstützen. DieMöglichkeiten, die Object Mapper für ein externes Schema-Management bieten, werden diskutiert. Abschließend wirdauf die mögliche Übertragbarkeit von Ansätzen aus dem Be-reich des Schema-Managements für XML-Dokumente ein-gegangen.

3.1 DBMS-internes Schema-Management

In [14] wurden die wichtigsten NoSQL-DBMS bezüglichder in Abschn. 2 aufgestellten Desiderata an das Schema-Management evaluiert. Dabei wurden die Column-Family-DBMS HBase [15], Cassandra [16] und Google Cloud Da-tastore (im folgenden Datastore genannt), welches intern aufMegastore [17] und BigTable [18] basiert, sowie die Doku-mentenorientierten DBMS MongoDB [3], CouchDB [6] undCouchbase [5] untersucht.

Die wichtigsten Ergebnisse sind in Abb. 7 dargestellt.Während � eine volle Erfüllung des Kriteriums bedeutet,kennzeichnet (�), dass das entsprechende Kriterium nur sehreingeschränkt erfüllt, aber zumindestens rudimentär vorhan-den ist. Man sieht, dass lediglich Cassandra bereits grund-legende Funktionalitäten bezüglich einer Struktur Definiti-on von Entity-Typen und sehr rudimentäre Möglichkeitenzur Definition von Constraints beinhaltet. Entity-Typen undAttribute können in Form von Column Families (Tabellen)und Columns (inkl. Datentypen) definiert werden. Die Erfül-lung der Strukturbedingungen und der Domain-Bedingungenwird durch das DBMS validiert. Da neue Columns zur Lauf-zeit mit „alter table“ hinzugefügt oder gelöscht werden kön-nen und das Vorhandensein von Werten für Columns nichterzwungen werden kann (existence constraint), ist trotzdemeine gewisse Schemaflexibilität möglich.

HBase unterstützt in sehr beschränktem Maße eineStruktur-Definition, da Tabellen mit Columns und ColumnFamilies existieren. Allerdings werden Columns durch ihrebloße Existenz in neuen Entities zu Tabellen hinzugefügt, sodass eine echte Struktur-Definition oder gar Validierung nichtmöglich ist. Datastore unterstützt die Benennung von Entity-Typen und erzwingt auch eine explizite Zuordnung von En-tities zu Entity-Typen. Allerdings sind die Strukturen derEntity-Typen so flexibel, dass keinerlei Validierung möglichist. Ebenso werden keine Operationen zur Schema-Evolutionunterstützt. Sowohl für HBase als auch Datastore existie-ren allerdings Schema-Bibliotheken, mit denen zuminde-stens einige Schema-Management-Funktionalitäten hinzu-gefügt werden können (siehe nächster Abschnitt).

Alle untersuchten Dokumentenorientierten DBMS (Mon-goDB, CouchDB und Couchbase) bieten „out of the box“ kei-nerlei Unterstützung für das Schema-Management. Auch diein MongoDB für die Anwendungsentwicklung zur Struktu-rierung empfohlenen Collections beinhalten keinerlei Mög-lichkeit zur Definition und Validierung von Entity-Typen.

Datenbanken ohne Schema?

Abb. 7 Stand der Unterstützung des Schema-Managements in NoSQL-DBMS bzw. mit externen Schema-Bibliotheken

Zusammenfassend bleibt festzuhalten, dass die wichtigstenNoSQL-DBMS, mit Ausnahme von Cassandra, bislang nursehr wenig Unterstützung für das Schema-Management an-bieten.

3.2 Externes Schema-Management mit Bibliotheken

Für einzelne Systeme existieren inzwischen Schema-Bibliotheken, mit denen einige Schema-Management-Funktionalitäten realisiert werden können. So hat etwa Goo-gle Cloud Datastore mit Verwendung des Python App En-gine SDK eine Data Modeling Library [4, 19]. Bei Verwen-dung dieser Library können sowohl die Struktur des Entity-Typs als auch Constraints vorab definiert und Entities spätergegen diese validiert werden. Allerdings werden Schema-Evolutionsoperationen auch von dieser Bibliothek bislangkaum unterstützt – der Fokus liegt auf der Definition ei-nes festen Schemas und der Validierung gegen dieses (sieheAbb. 7).

Einer der derzeit interessantesten Ansätze im Bereich desSchema-Managements für NoSQL-DBMS ist KijiSchema[20]. Dieser Aufsatz für HBase ermöglicht es, basierendauf einer JavaAPI oder einer Kommandozeilenschnittstelle,Schemata für HBase zu erstellen und zu managen. Dabei kön-nen Entity-Typen mit Attributen (in der HBase üblichen Na-mensgebung von Tabellen, Column Families und Columns)sowie eine Reihe von weiteren Parametern zur physischenSpeicherung der Daten definiert werden. Die Definition des

Schemas erfolgt dabei wahlweise mit einer Kiji-spezifischenDDL oder einer angepassten JSON-Notation.

Als einziges der betrachteten System bzw. ergänzen-den Bibliotheken erlaubt KijiSchema die Definition meh-rerer Schema-Versionen. Eine Reihe einfacher Operationenzur Schema-Evolution ist vorhanden. Es werden von Kiji-Schema allerdings nur solche Schemaänderungen für einenEntity-Typ angenommen, die sicherstellen, dass die neuenSchemata bzw. Schema-Versionen kompatibel zu den (nochgültigen) Vorgängerversionen sind. Dies bedeutet auch, dasskeine Datenmigrationsoperationen erfolgen.

3.3 Externes Schema-Management mit Object Mappern

Der Markt der Object Mapper für NoSQL-DBMS ist nochstark in der Entwicklung, aber bereits schon jetzt sehr viel-fältig [21]. Viele Object Mapper sind nur für ein DBMSentwickelt worden, wie Morphia [7] für MongoDB oderObjectify [8] für Datastore, bzw. spezielle JPA- und JDO-Implementierungen für Datastore (vgl. [22] und [23]). Es gibtallerdings auch Ausnahmen wie Kundera [9], welches u. a.mit Cassandra, HBase, MongoDB und CouchDB interagiert.Eine interessante Entwicklung ist, dass inzwischen auch imBereich des OR-Mappings etablierte Werkzeuge wie Hiber-nate in Form von Hibernate OGM [24] für NoSQL-DBMSeingesetzt werden können.

Die Definition von Entity-Typen und die Validierung vonEntities gegen diese ist eine inhärente Eigenschaft von ObjectMappern. Die Schema-Evolution wird bei der Verwendung

M. Klettke et al.

von Object Mappern nicht durch explizite Operationen aus-gedrückt, sondern durch die Änderung der Objekt-Definitionim Code. Dies löst allerdings nicht das Problem der Daten-migration. In Abschn. 1 wurde bereits exemplarisch gezeigt,wie einige dieser Mapper den Entwickler durch Bereitstel-lung von Annotationen bei der expliziten Programmierungder lazy Migration [7, 8] unterstützen – dort wurden aller-dings auch die Grenzen dieses programmatischen Ansatzesaufgezeigt.

3.4 Schema-Management für XML-Dokumente

Die in NoSQL-Datenbanksystemen verwendeten Daten-strukturen stellen eine etwas einfachere Struktur im Ver-gleich zu XML-Dokumenten dar. Daher lassen sich vieleMethoden des Schema-Managements aus diesem Bereichübertragen. Da das Schema im XML-Kontext physisch ge-trennt von den XML-Dokumenten gespeichert sein kann,benötigt man auch hier Verfahren zur konsistenten Evoluti-on von DTDs bzw. XML-Schemata und XML-Dokumenten[25, 26]. Verfahren zur Ableitung eines Schemas aus einerXML-Dokumentkollektion wurden ebenfalls vorgeschlagen(z. B. in [27]).

4 Umsetzung einer Schema-Management-Komponentefür NoSQL-Datenbanksysteme

Die Anforderungen an eine Schema-Management-Komponente wurden bereits in Abschn. 2 aufgezählt.Mit unserem Ansatz soll ein Werkzeug bereitgestelltwerden, das alle Aufgaben des Schema-Managementsbündeln und mit verschiedenen Arten von NoSQL-DBMSinteragieren kann. Welche Teilaufgaben dabei auf welcheWeise umgesetzt werden, wird nachfolgend beschrieben.

4.1 Wahl der Schema-Sprache

Bei der Wahl der Schema-Sprache gibt es drei ausschlagge-bende Kriterien: 1) Die Schema-Sprache soll für verschiede-ne Klassen von NoSQL-DBMS geeignet und 2) unabhängigvon einer bestimmten Programmiersprache sein. 3) Weiter-hin ist es wünschenswert, eine bereits etablierte Sprache zuverwenden.

Einige Systeme wie Kundera [9], Hibernate OGM[24] und Datastore [28] verwenden Java Persistence API(JPA [10])-Annotationen zur Beschreibung der Schema-Informationen. Gegen diesen Ansatz spricht das Kriteriumder Programmiersprachenunabhängigkeit. Eine Integrationin eine Anfragesprache (in Analogie zur DDL in SQL) er-scheint grundsätzlich sinnvoll und wird beispielsweise auchvon Cassandra [16] innerhalb der Cassandra Query Langua-ge (CQL) verfolgt. Allerdings existiert noch keine etablierte

und standardisierte Anfragesprache für NoSQL-DBMS, sodass dieser Ansatz derzeit nur proprietär möglich wäre.

Dokumentenorientierte DBMS wie MongoDB oderCouchDB speichern die Daten im (programmiersprachenun-abhängigen) JSON-Format. Für JSON etabliert sich derzeit,insbesondere im Bereich von Web-Anwendungen, JSON-Schema [29] als Sprache für die Definition der strukturellenMerkmale von JSON-Objekten. Da sich eine JSON-Schema-Definition auch sehr leicht auf Column-Family-DBMS über-tragen lässt, erfüllt JSON-Schema unsere Kritierien für dieWahl einer Schema-Sprache.

JSON-Schema bietet die Möglichkeit, die verschiedenenAttribute eines JSON-Objektes zu definieren. Attribute kön-nen nicht nur skalar, sondern auch vomTypArray oder Object(eine Menge von key:value-Paaren) sein. Damit lassen sichhierarchische Strukturen in JSON-Schema definieren.

Das folgende JSON-Schema illustriert diese Sprache füreinen Ausschnitt aus unserem laufendes Beispiel (siehe auchAbb. 1) und definiert die Struktur zur Speicherung von Fra-gen und Antwortmöglichkeiten.

{"type":"object","properties": {"text": { "type":"string" },"antworten": {"type":"array","items": { "type":"object","properties": {"text": { "type":"string" },"ist_richtig": { "type":"boolean" } } } } },

..."required": ["text", "antworten"]}...

} }

JSON-Schema eignet sich nicht nur für NoSQL-DBMS, diezur Klasse Dokumentenorientierte Datenbanksysteme gehö-ren und JSON-Dokumente speichern. Auch das Schema vonDaten in Column-Family-Datenbanksystemen kann mit die-ser Sprache beschrieben werden.

4.2 Validierung von Entities

Die meisten NoSQL-DBMS können keine strukturellenConstraints sicherstellen und keine Validierung der Entitiesgegen ein Schema vornehmen. In Programmiersprachen wiez. B. Java und Python können JSON-Dokumente verarbeitetwerden, dort stehen Bibliotheken zur Validierung gegen einJSON-Schema bereit. Damit lässt sich eine Validierung ineinfacher Weise außerhalb des Datenbanksystems durchfüh-ren.

Man benötigt dafür die Möglichkeit zur Speicherung einesJSON-Schemas oder verschiedener Versionen eines JSON-Schemas. Da JSON-Schema selbst JSON-Syntax verwendet,lässt sich das Schema sowohl innerhalb des NoSQL-DBMS

Datenbanken ohne Schema?

(wie in Abb. 5 gezeigt) als auch außerhalb als externe Kom-ponente (wie in Abb. 6 dargestellt) speichern.

Bei beiden Varianten muss bei jeder schreibenden Ope-ration auf den Daten (insert und update) eine Validierunggegen das Schema erfolgen, um die Konformität des Daten-bestandes garantieren zu können.

4.3 Schema-Evolution

Mit der Weiterentwicklung von Anwendungen wird es erfor-derlich, die gespeicherten Daten in NoSQL-DBMS anzupas-sen. Die Menge der gespeicherten Daten steigt, die Struktu-ren der Datensätze können sich ebenfalls ändern. Will manalle gespeicherten Daten an solche Änderungen anpassen, somuss eine Schema-Evolution durchgeführt werden.

Am einfachsten darstellbar ist eine solche Evolution durchdas Verwenden einer Evolutionssprache, mit der Schema-Änderungen formuliert werden können. Für relationale Da-tenbanktechnologie gibt es bereits ausgereifte Ansätze (wiePRISM [30]). Einen kompakten Überblick bietet [31], hierhaben sich die Begriffe SMOs für „Schema ModificationOperators“ [32] bzw. „Model Management Operators“ eta-bliert [31].

Eine Kollektion von SMOs speziell für NoSQL-Datenbanksysteme wird in [33] vorgestellt. Eine Evoluti-onssprache muss Operationen zum Anlegen, Verändern undLöschen (add, alter, delete entity) von Entity-Typen aufwei-sen. Zudem muss das Ergänzen, Umbenennen und Löschenvon Attributen (add, rename, delete property) möglich sein.

Viele NoSQL-DBMS stellen keine Join-Operationen be-reit und können damit Daten aus verschiedenen Entities nurin der Anwendung verbinden. Aus diesem Grund werdenAttribute teilweise redundant in verschiedenen Entity-Typengespeichert. Auf Schema-Ebene sind also auch copy- undmove-Operationen sinnvoll.

Zur Erläuterung entwickeln wir das Beispiel aus Kap. 1weiter. Wir möchten den Autoren der Fragen Rückkopplunggeben, wieviel Prozent der Nutzer ihre Fragen richtig be-antwortet haben. Dafür ergänzen wir ein Attribut zaehlerbei jeder Antwortmöglichkeit. Für jede richtige und für jedefalscheAntwortmöglichkeit wird darin gespeichert, wie häu-fig diese Antwort gegeben wurde. Mit einem solchen Zählerist es möglich, besonders einfache bzw. schwere Fragen zuerkennen.

Eine weitere Änderung ist das Hinzufügen einer katego-rie für die Fragen. In der ersten Version wurden die Quizfra-gen von beauftragten Autoren erstellt. Jeder Autor hatte nurfür ein zugeordnetes Fachgebiet Fragen geschrieben. Schnellstellte sich heraus, dass mehr Fragen benötigt werden. Mitder nächsten Version konnten alle Nutzer Fragen erstellen,zu den Fragen muss jetzt eine explizite Kategorie angegebenwerden.

Bereits persistierte Fragen sollen parallel zu den neuenFragen weiterhin im System verwendet werden, die kategoriewird dafür vom Entity Autor auch zur Frage kopiert.Der Übergang zwischen den Versionen wird durch folgendeSchema-Evolutionsschritte beschrieben (Definition der Evo-lutionssprache in [33]):

alter Entity Frage add antworten.zaehler = 0alter Entity Frage

copy Autor.fachgebiet to Frage.kategoriewhere (Autor.autorid = Frage.autorid)

Aufgrund der Veränderungen des Schemas ist auch ein Up-date aller gespeicherten Datensätze erforderlich, dieses wirdexemplarisch anhand der Update-Sprache der MongoDB ge-zeigt. Damit kann das Verändern und das Ergänzen von At-tributen beschrieben verwendet, die copy-Operation ist inPython dargestellt.

# Zaehler einfügen (add)db.Frage.update({},

{$set: {"antworten.0.zaehler": 0}}, true, true}})# Kategorie einfügen (copy)for entity in db.Autor.find():

kat= entity.get("fachgebiet")identifier= entity.get("autorid")db.Frage.update({"autorid": identifier,

"version": 2},{"$set": {"kategorie": kat}})

# die Updates erfolgten auf Version 2,# die Versionsnummer wird anschließend um 1 erhöhtdb.Frage.update({"version":2},

{$inc: {"version":1}}, false, true)

Durch Anwendung dieser Updates erhält man Dokumente ineiner Struktur, wie nachfolgend gezeigt.

{ "entity_type" : "Frage","id" : 4713,"text": "Was bietet MongoDB nicht?","antworten": [

{ "text": "Indexstrukturen","ist_richtig": false,"zaehler": 0 }, ... ],

"autorid": 1234,"kategorie": "Informatik","version": 3 }

Abbildung 8 veranschaulicht den allgemeinen Prozess derSchema-Evolution beim Übergang zwischen zwei Schema-Versionen. Die Schema-Evolutionssprache beschreibt dieÄnderungen auf dem Schema, damit einhergehend müs-sen Updates auf den gespeicherten NoSQL-Daten aus-geführt werden. Diese Updates lassen sich aus derSchema-Evolutionssprache generieren. Je nach eingesetz-tem NoSQL-DBMS gibt es sehr unterschiedliche Möglich-keiten zur Umsetzung von Updates.

Einige Systeme unterstützen Update-Operationen wie dasHinzufügen, Löschen und Umbenennen vonAttributen (z. B.

M. Klettke et al.

Abb. 8 Schema-Evolution und Updates von NoSQL-Daten

MongoDB), diese kann man für das Aktualisieren der be-reits gespeicherten Datensätze verwenden. In anderen Sy-steme (z. B. Couchbase) lassen sich die Update-Operationennur durch Auslesen und Verändern des Datensatzes in derAnwendung und Neuspeichern des veränderten Datensatzesumsetzen.

Für das Update der NoSQL-Daten und das Überführenin eine neue Version und die daraus resultierende Migrationder gespeicherten Entities sind zwei verschiedene Strategi-en vorstellbar: eager bzw. lazy Migration. Beide Variantenwurden schon in Abschn. 1 erläutert.

4.4 Schema-Extraktion

Wenn die Schema-Management-Komponente für schon exi-stierende Datenbestände eingesetzt werden soll, gibt es zweimögliche Vorgehensweisen:

• Ein Schema wird definiert und anschließend werden dieexistierenden Entities auf Konformität zum Schema über-prüft.

• Ein Schema wird durch Schema-Extraktion aus den bereitsvorhandenen Entities abgeleitet.

Für den Reverse-Engineering-Prozess der Schema-Extraktion ist es hilfreich zu wissen, welche Entitiesähnlich sind, also logisch wahrscheinlich zum gleichenEntity-Typ gehören. Außer Datastore unterstützt keinhier betrachtetes NoSQL-DBMS explizit die Speicherungeines Entity-Typs (siehe Abschn. 3). Allerdings sind inColumn-Familiy-DBMS typischerweise strukturell ähnlicheEntities in den gleichen Tabellen bzw. Column Familiesgespeichert. Dokumentenorientierte DBMS bieten alssolche Strukturierungsmöglichkeit teilweise Collections an(z. B. MongoDB). Die Schema-Extraktion soll das Schemafür die zum gleichen Entity-Typ gehörigen Entities ableiten– diese werden als Kollektion bezeichnet.

Abbildung 9 zeigt die schrittweise Ableitung eines JSON-Schemas aus JSON-Dokumenten.

1) Das Verfahren liest nacheinander die impliziten Struktu-rinformationen der JSON-Dokumente ein.

Abb. 9 Ableitung des Schemas für eine Dokumentmenge (Reverse-Enginering)

2) Daraus wird inkrementell ein Spanning Graph mitKnoten- und Kantenlabels (Abb. 9) aufgebaut, der alleStrukturvarianten der Kollektion beinhaltet und zusätz-lich die Informationen enthält, welche Strukturen in wel-chem Dokument auftreten. Das Vorgehen ist analog zumfür XML-Schema entwickelten Verfahren [27].

3) Aus dem Spanning Graph wird das JSON-Schema ab-geleitet, das alle strukturellen Varianten der Kollektionenthält.

Das Verfahren der Schema-Extraktion ist nicht nur auf einervollständigen Kollektionen einsetzbar. Man kann es in dergleichen Weise auf einem Ausschnitt der Daten verwenden.Hier sind vielfältige Varianten vorstellbar, wie die Selektionder Daten nach einem bestimmten Attributwert oder einenZeitbereich, sofern ein Attribut timestamp verfügbar ist.Es lassen sich dadurch verschiedene Schema-Varianten oder-Versionen zu einer vorhandenen Kollektion ableiten.

4.5 Data Cleansing

Die Struktur des Spanning Graphs mit Knoten- und Kanten-labels kann neben der Schema-Extraktion auch zum Findenvon strukturellen Ausreißern eingesetzt werden. Mit einemdefinierten Schwellwert können seltene Strukturmuster er-mittelt werden.

Neben den Schema-Informationen lässt sich also auch dieHäufigkeit des Auftretens ableiten:

{ "text": string, - 100 %"antworten": [ - 100 %{"text": string, - 100 %"ist_richtig": boolean}], - 100 %

"fehleranzahl": number, - 0.4 %"anzahl_maengel": number } - 99.6 %

Datenbanken ohne Schema?

Die prozentualen Angaben werden aus dem Spanning Graphdurch Vergleich der Knoten- und Kantenlabels abgeleitet.Wenn der Anwender diese selten auftretenden Muster alsFehler klassifiziert, können durch eine sich anschließen-de Schema-Evolution die strukturellen Ausreißer korrigiertwerden. Für das Beispiel würde das bedeuten, einerename-Operation für das Attribut fehleranzahl auf dem Sche-ma zu definieren, zugehörige Updates aller Entities, in denendas Attribut fehleranzahl auftritt, werden ausgeführt.

Das Data Cleansing nutzt also das Verfahren zur Schema-Extraktion, für die sich anschließende Korrektur der Datenwird die in Abschn. 4.3 vorgestellte Schema-Evolution an-gewendet.

5 Zusammenfassung und Ausblick

Mit der zunehmenden Beliebtheit von NoSQL-Systemenin der Anwendungsentwicklung steigen auch die An-sprüche an schema-flexible Datenbanksysteme. So wer-den Werkzeuge zur systematischen Schema-Verwaltungin naher Zukunft ebenso zum Ökosystem um NoSQL-Datenbanksysteme gehören, wie es heute für relationa-le Datenbanksysteme selbstverständlich ist. In diesem Ar-tikel stellen wir unsere Anforderungen an eine Schema-Management-Komponente als zentrales Werkzeug vor. Exi-stierende NoSQL-Datenbanksysteme bieten diese Funktio-nalität nur ansatzweise an.

Bei der Entwicklung eigener Werkzeuge für NoSQL-Datenbanksysteme sollen aber nicht nur die Techniken ausrelationalen Datenbanksystemen übernommen werden. Sokann es nicht das erklärte Ziel sein, einem schemalosen Sy-stem ein starres und globales Schema aufzuzwingen. Viel-mehr muss die Schema-Flexibilität für die Anwendungsent-wickler möglichst bewahrt werden: In der Konzeption ei-ner Schema-Management-Komponente eigens für NoSQL-Datenbanksysteme ist die Evolutionsfähigkeit des Schemassomit das wichtigste Kriterium.

Literatur

1. Ambler SW (2003) Agile database techniques. Wiley, Hoboken2. Rae I, Rollins E, Shute J, Sodhi S, Vingralek R (2013) Online,

asynchronous schema change in F1. In Proc. VLDB3. MongoDB (2014) http://www.mongodb.org/. Zugegriffen: 6. Juni

20144. Sanderson D (2012) Programming Google App engine, 2 Aufl.

O’Reilly Media, Inc, Sebastopol5. Couchbase (2014) http://www.couchbase.com/. Zugegriffen: 6. Ju-

ni 20146. Apache CouchDB (2014) docs.couchdb.org/. Zugegriffen: 6. Juni

20147. Morphia. A type-safe Java library for MongoDB (2014)

https://github.com/mongodb/morphia/. Zugegriffen: 6. Juni 20148. Objectify (2014) https://code.google.com/p/objectify-appengine/.

Zugegriffen: 6. Juni 2014

9. Kundera (2014) https://github.com/impetus-opensource/Kundera/wiki. Zugegriffen: 6. Juni 2014

10. Java Persistence 2.0 Expert Group: JSR 317 (2009) JavaTM Per-sistence API, Version 2.0. Sun Microsystems

11. Edlich S, Friedland A, Hampe J, Brauer B, Brückner M (2011)NoSQL: Einstieg in die Welt nichtrelationaler Web 2.0 Datenban-ken. Carl Hanser Verlag, München

12. Störl U (2014) NoSQL-Datenbanksysteme. In Kudraß T (Hrsg),Taschenbuch Datenbanken. Carl Hanser Verlag

13. Tiwari S (2011) Professional NoSQL. Wiley, Hoboken14. Glatzel H (2014) Schema-Management in NoSQL-Datenbank-

systemen. Master’s thesis, Hochschule Darmstadt15. Apache HBase (2014) http://hbase.apache.org/. Zugegriffen: 6. Ju-

ni 201416. Apache Cassandra (2014) http://cassandra.apache.org/. Zugegrif-

fen: 6. Juni 201417. Baker J, Bond C, Corbett JC, Furman J, Khorlin A, Larson J, Le-

on JM, Li Y, Lloyd A, Yushprakh V (2011) Megastore: providingscalable, highly available storage for interactive services. In Proc.CIDR, S 223–234

18. Chang F, Dean J, Ghemawat S, Hsieh WC, Wallach DA, BurrowsM, Chandra T, Fikes A, Gruber RE (2008) Bigtable: a distributedstorage system for structured data. ACM Trans Comput Syst 26(2)

19. Python App Engine SDK (2014) https://developers.google.com/appengine/docs/python/datastore/datamodeling/. Zugegriffen: 6.Juni 2014

20. Kiji Project (2014) http://www.kiji.org/. Zugegriffen: 6. Juni 201421. Wolf F, Betz H, Gropengießer F, Sattler KU (2013) Hibernating

in the cloud-implementation and evaluation of object-NoSQL-mapping. In Proc. BTW 2013

22. Google Developers: Using JPA with App Engine (2014)https://developers.google.com/appengine/docs/java/datastore/jpa/overview-dn2. Zugegriffen: 6. Juni 2014

23. Google Developers: Using JDO 2.3 with App Engine (2014)https://developers.google.com/appengine/docs/java/datastore/jdo/overview. Zugegriffen: 6. Juni 2014

24. Hibernate OGM (2014) http://hibernate.org/ogm/. Zugegriffen: 6.Juni 2014

25. Klettke M (2007) Modellierung, Bewertung und Evolution vonXML-Dokumentkollektionen. Habilitationsschrift. Logos Verlag,Berlin

26. Necaský M, Klímek J ,Malý J, Mlýnková I (2012) Evolutionand change management of XML-based systems. J Syst Softw85(3):683–707

27. Moh CH, Lim EP, Ng WK (2000) DTD-Miner, a tool for miningDTD from XML documents. In Proc. WECWIS

28. Google Developers: Google Cloud Datastore (2014) https://developers.google.com/datastore/. Zugegriffen: 6. Juni 2014

29. JSON Schema (2014) http://json-schema.org/. Zugegriffen: 6. Juni2014

30. Bai Y, Thakkar H, Wang H, Zaniolo C (2008) Time-stamp mana-gement and query execution in data stream management systems.IEEE Internet Computing 12(6):13–21

31. Doan A, Halevy AY, Ives ZG (2012) Principles of data integration.Morgan Kaufmann, Burlington

32. Curino C, Moon HJ, Deutsch A, Zaniolo C (2013) Automating thedatabase schema evolution process. VLDB J 22(1):73–98

33. Scherzinger S, Klettke M, Störl U (2013) Managing schema evo-lution in NoSQL data stores. In Proc. DBPL