Read Anytime Anywhere Easy Ebook Downloads at ebookmeta.

com

SQL and NoSQL Databases: Modeling, Languages,

Security and Architectures for Big Data Management
Michael Kaufmann

https://ebookmeta.com/product/sql-and-nosql-databases-
modeling-languages-security-and-architectures-for-big-data-
management-michael-kaufmann/

OR CLICK HERE

DOWLOAD EBOOK

Visit and Get More Ebook Downloads Instantly at https://ebookmeta.com

 Recommended digital products (PDF, EPUB, MOBI) that
you can download immediately if you are interested.

SQL and NoSQL Databases Modeling Languages Security and

Architectures for Big Data Management 2nd Edition Michael
Kaufmann
https://ebookmeta.com/product/sql-and-nosql-databases-modeling-
languages-security-and-architectures-for-big-data-management-2nd-
edition-michael-kaufmann/
ebookmeta.com

Python Data Persistence With SQL and NOSQL Databases 1st

Edition Lathkar

https://ebookmeta.com/product/python-data-persistence-with-sql-and-
nosql-databases-1st-edition-lathkar/

ebookmeta.com

NoSQL and SQL Data Modeling: Bringing Together Data,

Semantics, and Software First Edition Hills

https://ebookmeta.com/product/nosql-and-sql-data-modeling-bringing-
together-data-semantics-and-software-first-edition-hills/

ebookmeta.com

The Divorce from Hell Margie Majors Middle Aged Vampire

Slayer 2 2nd Edition Dewylde Saranna

https://ebookmeta.com/product/the-divorce-from-hell-margie-majors-
middle-aged-vampire-slayer-2-2nd-edition-dewylde-saranna/

ebookmeta.com
Optical Communications in the 5G Era 1st Edition Xiang Liu

https://ebookmeta.com/product/optical-communications-in-
the-5g-era-1st-edition-xiang-liu/

ebookmeta.com

Deep Waters Frank Waters Remembered in Letters and

Commentary 1st Edition Alan Louis Kishbaugh Alan Louis
Kishbaugh
https://ebookmeta.com/product/deep-waters-frank-waters-remembered-in-
letters-and-commentary-1st-edition-alan-louis-kishbaugh-alan-louis-
kishbaugh/
ebookmeta.com

The Atheist Manifesto 2nd Edition Christopher Hitchens

https://ebookmeta.com/product/the-atheist-manifesto-2nd-edition-
christopher-hitchens/

ebookmeta.com

European Revolutions and the Ottoman Balkans Nationalism

Violence and Empire in the Long Nineteenth Century 1st
Edition Dimitris Stamatopoulos
https://ebookmeta.com/product/european-revolutions-and-the-ottoman-
balkans-nationalism-violence-and-empire-in-the-long-nineteenth-
century-1st-edition-dimitris-stamatopoulos/
ebookmeta.com

Monster Girl Safari 3 1st Edition Roland Carlsson

https://ebookmeta.com/product/monster-girl-safari-3-1st-edition-
roland-carlsson/

ebookmeta.com
Loveless Osemanverse 10 1st Edition Alice Oseman

https://ebookmeta.com/product/loveless-osemanverse-10-1st-edition-
alice-oseman/

ebookmeta.com
Michael Kaufmann
Andreas Meier

SQL and NoSQL

Databases
Modeling, Languages, Security
and Architectures for Big Data
Management
Second Edition
SQL and NoSQL Databases
Michael Kaufmann • Andreas Meier

SQL and NoSQL

Databases
Modeling, Languages, Security
and Architectures for Big Data
Management

Second Edition
Michael Kaufmann Andreas Meier
Informatik Institute of Informatics
Hochschule Luzern Universität Fribourg
Rotkreuz, Switzerland Fribourg, Switzerland

ISBN 978-3-031-27907-2 ISBN 978-3-031-27908-9 (eBook)

https://doi.org/10.1007/978-3-031-27908-9

# The Editor(s) (if applicable) and The Author(s), under exclusive license to Springer Nature Switzerland
AG 2023
The first edition of this book was published by Springer Vieweg in 2019
This work is subject to copyright. All rights are solely and exclusively licensed by the Publisher, whether
the whole or part of the material is concerned, specifically the rights of reprinting, reuse of illustrations,
recitation, broadcasting, reproduction on microfilms or in any other physical way, and transmission
or information storage and retrieval, electronic adaptation, computer software, or by similar or
dissimilar methodology now known or hereafter developed.
The use of general descriptive names, registered names, trademarks, service marks, etc. in this publication
does not imply, even in the absence of a specific statement, that such names are exempt from the relevant
protective laws and regulations and therefore free for general use.
The publisher, the authors, and the editors are safe to assume that the advice and information in this
book are believed to be true and accurate at the date of publication. Neither the publisher nor the authors or
the editors give a warranty, expressed or implied, with respect to the material contained herein or for any
errors or omissions that may have been made. The publisher remains neutral with regard to jurisdictional
claims in published maps and institutional affiliations.

This Springer imprint is published by the registered company Springer Nature Switzerland AG
The registered company address is: Gewerbestrasse 11, 6330 Cham, Switzerland
Foreword

The term database has long since become part of people’s everyday vocabulary, for
managers and clerks as well as students of most subjects. They use it to describe a
logically organized collection of electronically stored data that can be directly
searched and viewed. However, they are generally more than happy to leave the
whys and hows of its inner workings to the experts.
Users of databases are rarely aware of the immaterial and concrete business
values contained in any individual database. This applies as much to a car importer’s
spare parts inventory as the IT solution containing all customer depots at a bank or
the patient information system of a hospital. Yet failure of these systems, or even
cumulative errors, can threaten the very existence of the respective company or
institution. For that reason, it is important for a much larger audience than just the
“database specialists” to be well-informed about what is going on. Anyone involved
with databases should understand what these tools are effectively able to do and
which conditions must be created and maintained for them to do so.
Probably the most important aspect concerning databases involves (a) the dis-
tinction between their administration and the data stored in them (user data) and
(b) the economic magnitude of these two areas. Database administration consists of
various technical and administrative factors, from computers, database systems, and
additional storage to the experts setting up and maintaining all these components—
the aforementioned database specialists. It is crucial to keep in mind that the
administration is by far the smaller part of standard database operation, constituting
only about a quarter of the entire efforts.
Most of the work and expenses concerning databases lie in gathering,
maintaining, and utilizing the user data. This includes the labor costs for all
employees who enter data into the database, revise it, retrieve information from
the database, or create files using this information. In the above examples, this means
warehouse employees, bank tellers, or hospital personnel in a wide variety of
fields—usually for several years.
In order to be able to properly evaluate the importance of the tasks connected with
data maintenance and utilization on the one hand and database administration on the
other hand, it is vital to understand and internalize this difference in the effort
required for each of them. Database administration starts with the design of the
database, which already touches on many specialized topics such as determining the

v
vi Foreword

consistency checks for data manipulation or regulating data redundancies, which are
as undesirable on the logical level as they are essential on the storage level. The
development of database solutions is always targeted on their later use, so
ill-considered decisions in the development process may have a permanent impact
on everyday operations. Finding ideal solutions, such as the golden mean between
too strict and too flexible when determining consistency conditions, may require
some experience. Unduly strict conditions will interfere with regular operations,
while excessively lax rules will entail a need for repeated expensive data repairs.
To avoid such issues, it is invaluable for anyone concerned with database
development and operation, whether in management or as a database specialist, to
gain systematic insight into this field of computer sciences. The table of contents
gives an overview of the wide variety of topics covered in this book. The title already
shows that, in addition to an in-depth explanation of the field of conventional
databases (relational model, SQL), the book also provides highly educational infor-
mation about current advancements and related fields, the keywords being NoSQL
and Big Data. I am confident that the newest edition of this book will once again be
well-received by both students and professionals—its authors are quite familiar with
both groups.

Professor Emeritus for Databases Carl August Zehnder

ETH Zürich
Zürich, Switzerland
Preface

It is remarkable how stable some concepts are in the field of databases. Information
technology is generally known to be subject to rapid development, bringing forth
new technologies at an unbelievable pace. However, this is only superficially the
case. Many aspects of computer science do not essentially change. This includes not
only the basics, such as the functional principles of universal computing machines,
processors, compilers, operating systems, databases and information systems, and
distributed systems, but also computer language technologies such as C, TCP/IP, or
HTML that are decades old but in many ways provide a stable fundament of the
global, earth-spanning information system known as the World Wide Web. Like-
wise, the SQL language (Structured Query Language) has been in use for almost five
decades and will remain so in the foreseeable future. The theory of relational
database systems was initiated in the 1970s by Codd (relation model) and
Chamberlin and Boyce (SEQUEL). However, these technologies have a major
impact on the practice of data management today. Especially, with the Big Data
revolution and the widespread use of data science methods for decision support,
relational databases and the use of SQL for data analysis are actually becoming more
important. Even though sophisticated statistics and machine learning are enhancing
the possibilities for knowledge extraction from data, many if not most data analyses
for decision support rely on descriptive statistics using SQL for grouped aggrega-
tion. SQL is also used in the field of Big Data with MapReduce technology. In this
sense, although SQL database technology is quite mature, it is more relevant today
than ever.
Nevertheless, the developments in the Big Data ecosystem brought new
technologies into the world of databases, to which we pay enough attention too.
Non-relational database technologies, which find more and more fields of applica-
tion under the generic term NoSQL, differ not only superficially from the classical
relational databases but also in the underlying principles. Relational databases were
developed in the twentieth century with the purpose of tightly organized, operational
forms of data management, which provided stability but limited flexibility. In
contrast, the NoSQL database movement emerged in the beginning of the new
century, focusing on horizontal partitioning, schema flexibility, and index-free
neighborhood with the goal of solving the Big Data problems of volume, variety,
and velocity, especially in Web-scale data systems. This has far-reaching

vii
viii Preface

consequences and leads to a new approach in data management, which deviate

significantly from the previous theories on the basic concept of databases: the way
data is modeled, how data is queried and manipulated, how data consistency is
handled, and how data is stored and made accessible. That is why in all chapters we
compare these two worlds, SQL and NoSQL databases.
In the first five chapters, we analyze in detail the management, modeling,
languages, security, and architecture of SQL databases, graph databases, and, in
the second English edition, new document databases. In Chaps. 6 and 7, we provide
an overview of other SQL- and NoSQL-based database approaches.
In addition to classic concepts such as the entity and relationship model and its
mapping in SQL or NoSQL database schemas, query languages, or transaction
management, we explain aspects for NoSQL databases such as the MapReduce
procedure, distribution options (fragments, replication), or the CAP theorem (con-
sistency, availability, partition tolerance).
In the second English edition, we offer a new in-depth introduction to document
databases with a method for modeling document structures, an overview of the
database language MQL, as well as security and architecture aspects. The new
edition also takes into account new developments in the Cypher language. The
topic of database security is newly introduced as a separate chapter and analyzed
in detail with regard to data protection, integrity, and transactions. Texts on data
management, database programming, and data warehousing and data lakes have
been updated. In addition, the second English edition explains the concepts of JSON,
JSON Schema, BSON, index-free neighborhood, cloud databases, search engines,
and time series databases.
We have launched a Website called sql-nosql.org, where we share teaching and
tutoring materials such as slides, tutorials for SQL and Cypher, case studies, and a
workbench for MySQL and Neo4j, so that language training can be done either with
SQL or with Cypher, the graph-oriented query language of the NoSQL database
Neo4j.
We thank Alexander Denzler and Marcel Wehrle for the development of the
workbench for relational and graph-oriented databases. For the redesign of the
graphics, we were able to work with Thomas Riediker. We thank him for his tireless
efforts. He has succeeded in giving the pictures a modern style and an individual
touch. In the ninth edition, we have tried to keep his style in our new graphics. For
the further development of the tutorials and case studies, which are available on the
website sql-nosql.org, we thank the computer science students Andreas Waldis,
Bettina Willi, Markus Ineichen, and Simon Studer for their contributions to the
tutorial in Cypher, respectively, to the case study Travelblitz with OpenOffice Base
and with Neo4J. For the feedback on the manuscript, we thank Alexander Denzler,
Daniel Fasel, Konrad Marfurt, Thomas Olnhoff, and Stefan Edlich for their willing-
ness to contribute to the quality of our work with reading our manuscript and with
providing valuable feedback. A heartfelt thank you goes out to Michael Kaufmann’s
wife Melody Reymond for proofreading our manuscript. Special thanks to Andy
Preface ix

Oppel of the University of California, Berkeley, for grammatical and technological

review of the English text. A big thank goes to Leonardo Milla of Springer, who has
supported us with patience and expertise.

Rotkreuz, Switzerland Michael Kaufmann

Fribourg, Switzerland Andreas Meier
October 2022
Contents

1 Database Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1 Information Systems and Databases . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 SQL Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.1 Relational Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.2 Structured Query Language SQL . . . . . . . . . . . . . . . . . . . 6
1.2.3 Relational Database Management System . . . . . . . . . . . . . 8
1.3 Big Data and NoSQL Databases . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.3.1 Big Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.3.2 NoSQL Database Management System . . . . . . . . . . . . . . . 12
1.4 Graph Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.4.1 Graph-Based Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.4.2 Graph Query Language Cypher . . . . . . . . . . . . . . . . . . . . 15
1.5 Document Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.5.1 Document Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.5.2 Document-Oriented Database Language MQL . . . . . . . . . . 19
1.6 Organization of Data Management . . . . . . . . . . . . . . . . . . . . . . . . 21
Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2 Database Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.1 From Requirements Analysis to Database . . . . . . . . . . . . . . . . . . . 25
2.2 The Entity-Relationship Model . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.2.1 Entities and Relationships . . . . . . . . . . . . . . . . . . . . . . . . 28
2.2.2 Associations and Association Types . . . . . . . . . . . . . . . . . 29
2.2.3 Generalization and Aggregation . . . . . . . . . . . . . . . . . . . . 32
2.3 Implementation in the Relational Model . . . . . . . . . . . . . . . . . . . . 35
2.3.1 Dependencies and Normal Forms . . . . . . . . . . . . . . . . . . . 35
2.3.2 Mapping Rules for Relational Databases . . . . . . . . . . . . . . 42
2.4 Implementation in the Graph Model . . . . . . . . . . . . . . . . . . . . . . . 47
2.4.1 Graph Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
2.4.2 Mapping Rules for Graph Databases . . . . . . . . . . . . . . . . . 51
2.5 Implementation in the Document Model . . . . . . . . . . . . . . . . . . . . 55
2.5.1 Document-Oriented Database Modeling . . . . . . . . . . . . . . 55

xi
xii Contents

2.5.2 Mapping Rules for Document Databases . . . . . . . . . . . . . . 59

2.6 Formula for Database Design . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
3 Database Languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.1 Interacting with Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.2 Relational Algebra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
3.2.1 Overview of Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
3.2.2 Set Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
3.2.3 Relation Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
3.2.4 Relationally Complete Languages . . . . . . . . . . . . . . . . . . . 80
3.3 Relational Language SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
3.3.1 Creating and Populating the Database Schema . . . . . . . . . . 81
3.3.2 Relational Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
3.3.3 Built-In Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
3.3.4 Null values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
3.4 Graph-Based Language Cypher . . . . . . . . . . . . . . . . . . . . . . . . . . 91
3.4.1 Creating and Populating the Database Schema . . . . . . . . . . 92
3.4.2 Relation Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
3.4.3 Built-In Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
3.4.4 Graph Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
3.5 Document-Oriented Language MQL . . . . . . . . . . . . . . . . . . . . . . 98
3.5.1 Creating and Filling the Database Schema . . . . . . . . . . . . . 98
3.5.2 Relation Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
3.5.3 Built-In Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
3.5.4 Null Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
3.6 Database Programming with Cursors . . . . . . . . . . . . . . . . . . . . . . 106
3.6.1 Embedding of SQL in Procedural Languages . . . . . . . . . . . 106
3.6.2 Embedding Graph-Based Languages . . . . . . . . . . . . . . . . . 109
3.6.3 Embedding Document Database Languages . . . . . . . . . . . . 109
Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
4 Database Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
4.1 Security Goals and Measures . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
4.2 Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
4.2.1 Authentication and Authorization in SQL . . . . . . . . . . . . . 113
4.2.2 Authentication in Cypher . . . . . . . . . . . . . . . . . . . . . . . . . 118
4.2.3 Authentication and Authorization in MQL . . . . . . . . . . . . . 121
4.3 Integrity Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
4.3.1 Relational Integrity Constraints . . . . . . . . . . . . . . . . . . . . . 127
4.3.2 Integrity Constraints for Graphs in Cypher . . . . . . . . . . . . 129
4.3.3 Integrity Constraints in Document Databases with MQL . . . 132
4.4 Transaction Consistency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
4.4.1 Multi-user Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
4.4.2 ACID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Contents xiii

4.4.3 Serializability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

4.4.4 Pessimistic Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
4.4.5 Optimistic Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
4.4.6 Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
4.5 Soft Consistency in Massive Distributed Data . . . . . . . . . . . . . . . . 144
4.5.1 BASE and the CAP Theorem . . . . . . . . . . . . . . . . . . . . . . 144
4.5.2 Nuanced Consistency Settings . . . . . . . . . . . . . . . . . . . . . 146
4.5.3 Vector Clocks for the Serialization of Distributed
Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
4.5.4 Comparing ACID and BASE . . . . . . . . . . . . . . . . . . . . . . 149
4.6 Transaction Control Language Elements . . . . . . . . . . . . . . . . . . . . 151
4.6.1 Transaction Control in SQL . . . . . . . . . . . . . . . . . . . . . . . 151
4.6.2 Transaction Management in the Graph Database Neo4J
and in the Cypher Language . . . . . . . . . . . . . . . . . . . . . . . 153
4.6.3 Transaction Management in MongoDB and MQL . . . . . . . 155
Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
5 System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
5.1 Processing of Homogeneous and Heterogeneous Data . . . . . . . . . . 159
5.2 Storage and Access Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
5.2.1 Indexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
5.2.2 Tree Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
5.2.3 Hashing Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
5.2.4 Consistent Hashing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
5.2.5 Multi-dimensional Data Structures . . . . . . . . . . . . . . . . . . 168
5.2.6 Binary JavaScript Object Notation BSON . . . . . . . . . . . . . 171
5.2.7 Index-Free Adjacency . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
5.3 Translation and Optimization of Relational Queries . . . . . . . . . . . . 175
5.3.1 Creation of Query Trees . . . . . . . . . . . . . . . . . . . . . . . . . . 175
5.3.2 Optimization by Algebraic Transformation . . . . . . . . . . . . 178
5.3.3 Calculation of Join Operators . . . . . . . . . . . . . . . . . . . . . . 180
5.3.4 Cost-Based Optimization of Access Paths . . . . . . . . . . . . . 182
5.4 Parallel Processing with MapReduce . . . . . . . . . . . . . . . . . . . . . . 184
5.5 Layered Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
5.6 Use of Different Storage Structures . . . . . . . . . . . . . . . . . . . . . . . 187
5.7 Cloud Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
6 Post-relational Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
6.1 The Limits of SQL and What Lies Beyond . . . . . . . . . . . . . . . . . . 193
6.2 Federated Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
6.3 Temporal Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
6.4 Multi-dimensional Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
6.5 Data Warehouse and Data Lake Systems . . . . . . . . . . . . . . . . . . . 204
6.6 Object-Relational Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
6.7 Knowledge Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
xiv Contents

6.8 Fuzzy Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216

Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
7 NoSQL Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
7.1 Development of Non-relational Technologies . . . . . . . . . . . . . . . . 223
7.2 Key-Value Stores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
7.3 Column-Family Stores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
7.4 Document Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
7.5 XML Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
7.6 Graph Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
7.7 Search Engine Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
7.8 Time Series Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243

Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
Database Management
1

1.1 Information Systems and Databases

The evolution from the industrial society via the service society to the information
and knowledge society is represented by the assessment of information as a factor in
production. The following characteristics distinguish information from material
goods:

• Representation: Information is specified by data (signs, signals, messages, or

language elements).
• Processing: Information can be transmitted, stored, categorized, found, or
converted into other representation formats using algorithms and data structures
(calculation rules).
• Combination: Information can be freely combined. The origin of individual parts
cannot be traced. Manipulation is possible at any point.
• Age: Information is not subject to physical aging processes.
• Original: Information can be copied without limit and does not distinguish
between original and copy.
• Vagueness: Information can be imprecise and of differing validity (quality).
• Medium: Information does not require a fixed medium and is therefore indepen-
dent of location.

These properties clearly show that digital goods (information, software, multime-
dia, etc.), i.e., data, are vastly different from material goods in both handling and
economic or legal evaluation. A good example is the loss in value that physical
products often experience when they are used—the shared use of information, on the
other hand, may increase its value. Another difference lies in the potentially high
production costs for material goods, while information can be multiplied easily and
at significantly lower costs (only computing power and storage medium). This
causes difficulties in determining property rights and ownership, even though digital
watermarks and other privacy and security measures are available.

# The Author(s), under exclusive license to Springer Nature Switzerland AG 2023 1

M. Kaufmann, A. Meier, SQL and NoSQL Databases,
https://doi.org/10.1007/978-3-031-27908-9_1
2 1 Database Management

Information System

Communication
Database System Application Software network
or WWW

User
 User guidance
Database  Dialog design Request
Management
 Business logic
 Data querying Response
 Data manipulation
Database  Access permissions
Storage  Data protection

Fig. 1.1 Architecture and components of information systems

Considering data as the basis of information as a production factor in a company

has significant consequences:

• Basis for decision-making: Data allows well-informed decisions, making it vital

for all organizational functions.
• Quality level: Data can be available from different sources; information quality
depends on the availability, correctness, and completeness of the data.
• Need for investments: Data gathering, storage, and processing cause work and
expenses.
• Degree of integration: Fields and holders of duties within any organization are
connected by informational relations, meaning that the fulfillment of the said
duties largely depends on the degree of data integration.

Once data is viewed as a factor in production, it must be planned, governed,

monitored, and controlled. This makes it necessary to see data management as a task
for the executive level, inducing a major change within the company. In addition to
the technical function of operating the information and communication infrastructure
(production), planning and design of data flows (application portfolio) is crucial.
As shown in Fig. 1.1, an information system enables users to store and connect
information interactively, to ask questions, and to get answers. Depending on the
type of information system, the acceptable questions may be limited. There are,
however, open information systems and online platforms in the World Wide Web
that use search engines to process arbitrary queries.
The computer-based information system in Fig. 1.1 is connected to a communi-
cation network such as the World Wide Web in order to allow for online interaction
1.2 SQL Databases 3

and global information exchange in addition to company-specific analyses. Any

information system of a certain size uses database systems to avoid the necessity to
redevelop database management, querying, and analysis every time it is used.
Database systems are software for application-independently describing, storing,
and querying data. All database systems contain a storage and a management
component. The storage component called the database includes all data stored in
organized form plus their description. The management component called the
database management system (DBMS) contains a query and data manipulation
language for evaluating and editing the data and information. This component not
only does serve the user interface but also manages all access and editing
permissions for users and applications.
SQL databases (SQL = Structured Query Language, cf. Sect. 1.2) are the most
common in practical use. However, providing real-time Web-based services
referencing heterogeneous data sets is especially challenging (cf. Sect. 1.3 on Big
Data) and has called for new solutions such as NoSQL approaches (cf. Sect. 1.4).
When deciding whether to use relational or non-relational technologies, pros and
cons have to be considered carefully—in some use cases, it may even be ideal to
combine different technologies (cf. operating a Web shop in Sect. 5.6). Modern
hybrid DBMS approaches combine SQL with non-relational aspects, either by
providing NoSQL features in relational databases or by exposing an SQL querying
interface to non-relational databases. Depending on the database architecture of
choice, data management within the company must be established and developed
with the support of qualified experts (Sect. 1.5). Further reading is listed in Sect. 1.6.

1.2 SQL Databases

1.2.1 Relational Model

One of the simplest and most intuitive ways to collect and present data is in a table.
Most tabular data sets can be read and understood without additional explanations.
To collect information about employees, a table structure as shown in Fig. 1.2 can
be used. The all-capitalized table name EMPLOYEE refers to the entire table, while
the individual columns are given the desired attribute names as headers, for example,
the employee number “E#,” the employee’s name “Name,” and their city of resi-
dence “City.”
An attribute assigns a specific data value from a predefined value range called
domain as a property to each entry in the table. In the EMPLOYEE table, the
attribute E# allows to uniquely identify individual employees, making it the key of
the table. To mark key attributes more clearly, they will be written in italics in the
table headers throughout this book.1 The attribute City is used to label the respective

1
Some major works of database literature mark key attributes by underlining.
4 1 Database Management

Table name

EMPLOYEE Attribute
E# Name City

Key attribute

Fig. 1.2 Table structure for an EMPLOYEE table

Column (or attribute)

EMPLOYEE

E# Name City
E19 Stewart Stow

E4 Bell Kent

E1 Murphy Kent

E7 Howard Cleveland

Data value Record

(row or tuple)

Fig. 1.3 EMPLOYEE table with manifestations

places of residence and the attribute Name for the names of the respective employees
(Fig. 1.3).
The required information of the employees can now easily be entered row by row.
In the columns, values may appear more than once. In our example, Kent is listed as
the place of residence of two employees. This is an important fact, telling us that both
employee Murphy and employee Bell are living in Kent. In our EMPLOYEE table,
not only cities but also employee names may exist multiple times. For that reason,
the aforementioned key attribute E# is required to uniquely identify each employee
in the table.
1.2 SQL Databases 5

Identification Key
An identification key or just key of a table is one attribute or a minimal combination
of attributes whose values uniquely identify the records (called rows or tuples)
within the table. If there are multiple keys, one of them can be chosen as the primary
key. This short definition lets us infer two important properties of keys:

• Uniqueness: Each key value uniquely identifies one record within the table, i.e.,
different tuples must not have identical keys.
• Minimality: If the key is a combination of attributes, this combination must be
minimal, i.e., no attribute can be removed from the combination without
eliminating the unique identification.

The requirements of uniqueness and minimality fully characterize an identifica-

tion key. However, keys are also commonly used to reference tables among
themselves.
Instead of a natural attribute or a combination of natural attributes, an artificial
attribute can be introduced into the table as key. The employee number E# in our
example is an artificial attribute, as it is not a natural characteristic of the employees.
While we are hesitant to include artificial keys or numbers as identifying
attributes, especially when the information in question is personal, natural keys
often result in issues with uniqueness and/or privacy. For example, if a key is
constructed from parts of the name and the date of birth, it may not necessarily be
unique. Moreover, natural or intelligent keys divulge information about the respec-
tive person, potentially infringing on their privacy.
Due to these considerations, artificial keys should be defined application-inde-
pendent and without semantics (meaning, informational value). As soon as any
information can be deduced from the data values of a key, there is room for
interpretation. Additionally, it is quite possible that the originally well-defined
principle behind the key values changes or is lost over time.

Table Definition
To summarize, a table is a set of rows presented in tabular form. The data records
stored in the table rows, also called tuples, establish a relation between singular data
values. According to this definition, the relational model considers each table as a set
of unordered tuples. Tables in this sense meet the following requirements:

• Table name: A table has a unique table name.

• Attribute name: All attribute names are unique within a table and label one
specific column with the required property.
• No column order: The number of attributes is not set, and the order of the
columns within the table does not matter.
• No row order: The number of tuples is not set, and the order of the rows within
the table does not matter.
6 1 Database Management

EMPLOYEE
E# Name City
E19 Stewart Stow
E4 Bell Kent
E1 Murphy Kent
E7 Howard Cleveland

Example query:
“Select the names of the employees living in Kent.”

Formulation with SQL: Results table:

SELECT Name Name
FROM EMPLOYEE
WHERE City = 'Kent' Bell
Murphy

Fig. 1.4 Formulating a query in SQL

• Identification key: Strictly speaking, tables represent relations in the mathemati-

cal sense only if there are no duplicate rows. Therefore, one attribute or a
combination of attributes can uniquely identify the tuples within the table and is
declared the identification key.

1.2.2 Structured Query Language SQL

As explained, the relational model presents information in tabular form, where each
table is a set of tuples (or records) of the same type. Seeing all the data as sets makes
it possible to offer query and manipulation options based on sets.
The result of a selective operation, for example, is a set, i.e., each search result is
returned by the database management system as a table. If no tuples of the scanned
table show the respective properties, the user gets a blank result table. Manipulation
operations similarly target sets and affect an entire table or individual table sections.
The primary query and data manipulation language for tables is called Structured
Query Language, usually shortened to SQL (see Fig. 1.4). It was standardized by
1.2 SQL Databases 7

ANSI (American National Standards Institute) and ISO (International Organization

for Standardization).2
SQL is a descriptive language, as the statements describe the desired result
instead of the necessary computing steps. SQL queries follow a basic pattern as
illustrated by the query from Fig. 1.4:
“SELECT the attribute Name FROM the EMPLOYEE table WHERE the city is
Kent.”
A SELECT-FROM-WHERE query can apply to one or several tables and always
generates a table as a result. In our example, the query would yield a results table
with the names Bell and Murphy, as desired.
The set-based method offers users a major advantage, since a single SQL query
can trigger multiple actions within the database management system. Relational
query and data manipulation languages are descriptive. Users get the desired results
by merely setting the requested properties in the SELECT expression. They do not
have to provide the procedure for computing the required records. The database
management system takes on this task, processes the query or manipulation with its
own search and access methods, and generates the results table.
With procedural database languages on the other hand, the methods for retrieving
the requested information must be programmed by the user. In that case, each query
yields only one record, not a set of tuples.
With its descriptive query formula, SQL requires only the specification of the
desired selection conditions in the WHERE clause, while procedural languages
require the user to specify an algorithm for finding the individual records. As an
example, let us take a look at a query language for hierarchical databases (see
Fig. 1.5): For our initial operation, we use GET_FIRST to search for the first record
that meets our search criteria. Next, we access all other corresponding records
individually with the command GET_NEXT until we reach the end of the file or a
new hierarchy level within the database.
Overall, we can conclude that procedural database management languages use
record-based or navigating commands to manipulate collections of data, requiring
some experience and knowledge of the database’s inner structure from the users.
Occasional users basically cannot independently access and use the contents of a
database. Unlike procedural languages, relational query and manipulation languages
do not require the specification of access paths, processing procedures, or naviga-
tional routes, which significantly reduces the development effort for database
utilization.
If database queries and analyses are to be done by end users instead of IT
professionals, the descriptive approach is extremely useful. Research on descriptive
database interfaces has shown that even occasional users have a high probability of
successfully executing the desired analyses using descriptive language elements.
Figure 1.5 also illustrates the similarities between SQL and natural language. In

2
ANSI is the national standards organization of the USA. The national standardization
organizations are part of ISO.
8 1 Database Management

Natural language:

“Select the names of the employees living in Kent.”

Descriptive language:

SELECT Name
FROM EMPLOYEE
WHERE City = 'Kent'

Procedural language:

get first EMPLOYEE

while status = 0 do
begin
if City = 'Kent' then print(Name)
get next EMPLOYEE
end

Fig. 1.5 The difference between descriptive and procedural languages

fact, there are modern relational database management systems that can be accessed
with natural language.

1.2.3 Relational Database Management System

Databases are used in the development and operation of information systems in order
to store data centrally, permanently, and in a structured manner.
As shown in Fig. 1.6, relational database management systems are integrated
systems for the consistent management of tables. They offer service functionalities
and the descriptive language SQL for data description, selection, and manipulation.
Every relational database management system consists of a storage and a man-
agement component. The storage component stores both data and the relationships
between pieces of information in tables. In addition to tables with user data from
various applications, it contains predefined system tables necessary for database
operation. These contain descriptive information and can be queried, but not
manipulated, by users.
The management component’s most important part is the language SQL for
relational data definition, selection, and manipulation. This component also contains
service functions for data restoration after errors, for data protection, and for backup.
Relational database management systems (RDBMS) have the following properties:
1.2 SQL Databases 9

Relational Database System



+


 Data and relationships in tables
 Metadata in system tables

 Query and manipulation language SQL

 Special functions (recovery, reorganization,
security, data protection, etc.) with SQL

Fig. 1.6 Basic structure of a relational database management system

• Model: The database model follows the relational model, i.e., all data and data
relations are represented in tables. Dependencies between attribute values of
tuples or multiple instances of data can be discovered (cf. normal forms in Sect.
2.3.1).
• Schema: The definitions of tables and attributes are stored in the relational
database schema. The schema further contains the definition of the identification
keys and rules for integrity assurance.
• Language: The database system includes SQL for data definition, selection, and
manipulation. The language component is descriptive and facilitates analyses and
programming tasks for users.
• Architecture: The system ensures extensive data independence, i.e., data and
applications are mostly segregated. This independence is reached by separating
the actual storage component from the user side using the management compo-
nent. Ideally, physical changes to relational databases are possible without having
to adjust related applications.
• Multi-user operation: The system supports multi-user operation (cf. Sect. 4.1),
i.e., several users can query or manipulate the same database at the same time.
The RDBMS ensures that parallel transactions in one database do not interfere
with each other or worse, with the correctness of data (Sect. 4.2).
• Consistency assurance: The database management system provides tools for
ensuring data integrity, i.e., the correct and uncompromised storage of data.
• Data security and data protection: The database management system provides
mechanisms to protect data from destruction, loss, or unauthorized access.

NoSQL database management systems meet these criteria only partially (see
Chaps. 4 and 7). For that reason, most corporations, organizations, and especially
10 1 Database Management

SMEs (small and medium enterprises) rely heavily on relational database manage-
ment systems. However, for spread-out Web applications or applications handling
Big Data, relational database technology must be augmented with NoSQL technol-
ogy in order to ensure uninterrupted global access to these services.

1.3 Big Data and NoSQL Databases

1.3.1 Big Data

The term Big Data is used to label large volumes of data that push the limits of
conventional software. This data can be unstructured (see Sect. 5.1) and may
originate from a wide variety of sources: social media postings; e-mails; electronic
archives with multimedia content; search engine queries; document repositories of
content management systems; sensor data of various kinds; rate developments at
stock exchanges; traffic flow data and satellite images; smart meters in household
appliances; order, purchase, and payment processes in online stores; e-health
applications; monitoring systems; etc.
There is no binding definition for Big Data yet, but most data specialists will
agree on three Vs: volume (extensive amounts of data), variety (multiple formats:
structured, semi-structured, and unstructured data; see Fig. 1.7), and velocity (high-
speed and real-time processing). Gartner Group’s IT glossary offers the following
definition:

Big Data
“Big data is high-volume, high-velocity and high-variety information assets that
demand cost-effective, innovative forms of information processing for enhanced
insight and decision making.”

Multimedia

Text Graphics Image Audio Video

 Continuous text  City map  Photograph  Language  Film

 Structured text  Road map  Satellite image  Music  Animation
 Collection of  Technical  X-ray image  Sounds  Ads
texts drawing etc.  Animal sounds  Video
 Tags etc.  3D graphics  Synthetic conference etc.
etc. sounds etc.

Fig. 1.7 Variety of sources for Big Data

1.3 Big Data and NoSQL Databases 11

With this definition, Big Data are information assets for companies. It is indeed
vital for companies and organizations to generate decision-relevant knowledge in
order to survive. In addition to internal information systems, they increasingly utilize
the numerous resources available online to better anticipate economic, ecologic, and
social developments on the markets.
Big Data is a challenge faced by not only for-profit-oriented companies in digital
markets but also governments, public authorities, NGOs (non-governmental
organizations), and NPOs (nonprofit organizations).
A good example are programs to create smart or ubiquitous cities, i.e., by using
Big Data technologies in cities and urban agglomerations for sustainable develop-
ment of social and ecologic aspects of human living spaces. They include projects
facilitating mobility, the use of intelligent systems for water and energy supply, the
promotion of social networks, expansion of political participation, encouragement of
entrepreneurship, protection of the environment, and an increase of security and
quality of life.
All use of Big Data applications requires successful management of the three Vs
mentioned above:

• Volume: There are massive amounts of data involved, ranging from giga- to
zettabytes (megabyte, 106 bytes; gigabyte, 109 bytes; terabyte, 1012 bytes;
petabyte, 1015 bytes; exabyte, 1018 bytes; zettabyte, 1021 bytes).
• Variety: Big Data involves storing structured, semi-structured, and unstructured
multimedia data (text, graphics, images, audio, and video; cf. Fig. 1.7).
• Velocity: Applications must be able to process and analyze data streams in real
time as the data is gathered.

Big Data can be considered an information asset, which is why sometimes

another V is added:

• Value: Big Data applications are meant to increase the enterprise value, so
investments in personnel and technical infrastructure are made where they will
bring leverage or added value can be generated.

To complete our discussion of the concept of Big Data, we will look at another V:

• Veracity: Since much data is vague or inaccurate, specific algorithms evaluating

the validity and assessing result quality are needed. Large amounts of data do not
automatically mean better analyses.

Veracity is an important factor in Big Data, where the available data is of variable
quality, which must be taken into consideration in analyses. Aside from statistical
methods, there are fuzzy methods of soft computing which assign a truth value
between 0 (false) and 1 (true) to any result or statement.
12 1 Database Management

1.3.2 NoSQL Database Management System

Before Ted Codd’s introduction of the relational model, non-relational databases

such as hierarchical or network-like databases existed. After the development of
relational database management systems, non-relational models were still used in
technical or scientific applications. For instance, running CAD (computer-aided
design) systems for structural or machine components on relational technology is
rather difficult. Splitting technical objects across a multitude of tables proved
problematic, as geometric, topological, and graphical manipulations all had to be
executed in real time.
The omnipresence of the Internet and numerous Web-based and mobile
applications has provided quite a boost to the relevance of non-relational data
concepts vs. relational ones, as managing Big Data applications with relational
database technology is hard to impossible.
While “non-relational” would be a better description than NoSQL, the latter has
become established with database researchers and providers on the market over the
last few years.

NoSQL
The term NoSQL is used for any non-relational database management approach
meeting at least one of two criteria:

• The data is not stored in tables.

• The database language is not SQL.

NoSQL technologies are in demand, especially where the applications in the

framework for Big Data (speed, volume, variety) are in the foreground, because
non-relational structures are often better suited for this. Sometimes, the term NoSQL
is translated to “Not only SQL.” This is to express that non-relational storage and
language functions are used in addition to SQL in an application. For example, there
are SQL language interfaces for non-relational systems, either native or as
middleware; and relational databases today also offer NoSQL functions, e.g., docu-
ment data types or graph analyses.
The basic structure of a NoSQL database system is outlined in Fig. 1.8. Mostly, a
NoSQL database system is subject to a massively distributed data storage architec-
ture. Data is stored in alternative non-tabular structures depending on the type of
NoSQL database. As an example, Fig. 1.9 shows key/value stores, document
databases, and graph databases. To ensure high availability and to protect the
NoSQL database system against failures, different replication concepts are
supported. With a massively distributed and replicated computer architecture, paral-
lel evaluation procedures can be used. The analysis of extensive data volumes or the
search for specific facts can be accelerated with distributed computation procedures.
In the MapReduce procedure, subtasks are distributed to various computer nodes,
and simple key-value pairs are extracted (Map) before the partial results are com-
bined and output (Reduce).
1.3 Big Data and NoSQL Databases 13

NoSQL Database System

 Data in columns, documents, or graphs

 Distributed data replicas

 Parallel execution
 Weak to strong consistency

Fig. 1.8 Basic structure of a NoSQL database management system

Key-value store Document store Graph database

Document E
DI

Key= Session-ID 1 Document E

RE

Document D
Document
Document C D MOVIE
CT

Value = Order-Nr 1
ED

Document
DocumentB C
_B

Document A
Document B
Y

Key= Session-ID 2
AC

Key= Order-Nr A
Document
TE

Value = Order-Nr 2 Customer profile DIRECTOR

D_
IN

Shopping cart
Key= Session-ID 3 Item 1
Item 2 ACTOR
Value = Order-Nr 3
Item 3

Fig. 1.9 Three different NoSQL databases

14 1 Database Management

In massively distributed computer networks, differentiated consistency concepts

are also offered. Strong consistency means that the NoSQL database system
guarantees consistency at all times. Weak consistency means that changes to
replicated nodes are tolerated with a delay and can lead to short-term inconsistencies.

NoSQL Database System

Storage systems are considered NoSQL database systems if they meet some of the
following requirements:

• Model: The underlying database model is not relational.

• Data: The database system includes a large amount of data (volume), flexible
data structures (variety), and real-time processing (velocity).
• Schema: The database management system is not bound by a fixed database
schema.
• Architecture: The database architecture supports massively scalable
applications.
• Replication: The database management system supports data replication.
• Consistency assurance: According to the CAP theorem, consistency may be
ensured with a delay to prioritize high availability and partition tolerance.

Figure 1.9 shows three different NoSQL database management systems. Key-
value stores (see also Sect. 7.2) are the simplest version. Data is stored as an
identification key <key = "key"> and a list of values <value = "value 1", "value
2", . . .>. A good example is an online store with session management and shopping
basket. The session ID is the identification key; the order number is the value stored
in the cache. In document stores, records are managed as documents within the
NoSQL database. These documents are structured files which describe an entire
subject matter in a self-contained manner. For instance, together with an order
number, the individual items from the basket are stored as values in addition to the
customer profile. The third example shows a graph database on movies and actors
discussed in the next section.

1.4 Graph Databases

1.4.1 Graph-Based Model

NoSQL databases support various database models (see Fig. 1.9). Here, we discuss
graph databases as a first example to look at and discuss its characteristics.

Property Graph
Property graphs consist of nodes (concepts, objects) and directed edges
(relationships) connecting the nodes. Both nodes and edges are given a label and
can have properties. Properties are given as attribute-value pairs with the names of
attributes and the respective values.
1.4 Graph Databases 15

MOVIE
Title HAS
Year
GENRE
Type

ACTED_IN
Role DIRECTED_BY

ACTOR
Name DIRECTOR
Birthyear Name
Nationality

Fig. 1.10 Section of a property graph on movies

A graph abstractly presents the nodes and edges with their properties. Figure 1.10
shows part of a movie collection as an example. It contains the nodes MOVIE with
attributes Title and Year (of release), GENRE with the respective Type (e.g., crime,
mystery, comedy, drama, thriller, western, science fiction, documentary, etc.),
ACTOR with Name and Year of Birth, and DIRECTOR with Name and Nationality.
The example uses three directed edges: The edge ACTED_IN shows which artist
from the ACTOR node starred in which film from the MOVIE node. This edge also
has a property, the Role of the actor in the movie. The other two edges, HAS and
DIRECTED_BY, go from the MOVIE node to the GENRE and DIRECTOR node,
respectively.
In the manifestation level, i.e., the graph database, the property graph contains the
concrete values (Fig. 1.11). For each node and for each edge, a separate record is
stored. Thus, in contrast to relational databases, the connections between the data are
not stored and indexed as key references, but as separate records. This leads to
efficient processing of network analyses.

1.4.2 Graph Query Language Cypher

Cypher is a declarative query language for extracting patterns from graph databases.
ISO plans to extend Cypher to become the international standard for graph-based
database languages as Graph Query Language (GQL) by 2023.
Users define their query by specifying nodes and edges. The database manage-
ment system then calculates all patterns meeting the criteria by analyzing the
16 1 Database Management

ACTOR
Name: Keanu Reeves
Birthyear: 1964

AC ole
k
ar

R
TE : N
M

DIRECTED_BY

D eo
D IN

_I
ak
e : D_

N
on
ol E
R CT
A

MOVIE MOVIE
Title: Man of Tai Chi Title: The Matrix
Year: 2013 Year: 1999

Fig. 1.11 Section of a graph database on movies

possible paths (connections between nodes via edges). The user declares the struc-
ture of the desired pattern, and the database management system’s algorithms
traverse all necessary connections (paths) and assemble the results.
As described in Sect. 1.4.1, the data model of a graph database consists of nodes
(concepts, objects) and directed edges (relationships between nodes). In addition to
their name, both nodes and edges can have a set of properties (see Property Graph in
Sect. 1.4.1). These properties are represented by attribute-value pairs.
Figure 1.11 shows a segment of a graph database on movies and actors. To keep
things simple, only two types of nodes are shown: ACTOR and MOVIE. ACTOR
nodes contain two attribute-value pairs, specifically (Name: FirstName LastName)
and (YearOfBirth: Year).
The segment in Fig. 1.11 includes different types of edges: The ACTED_IN
relationship represents which actors starred in which movies. Edges can also have
properties if attribute-value pairs are added to them. For the ACTED_IN relation-
ship, the respective roles of the actors in the movies are listed. For example, Keanu
Reeves is the hacker Neo in “The Matrix.”
Nodes can be connected by multiple relationship edges. The movie “Man of Tai
Chi” and actor Keanu Reeves are linked not only by the actor’s role (ACTED_IN)
but also by the director position (DIRECTED_BY). The diagram therefore shows
that Keanu Reeves both directed the movie “Man of Tai Chi” and starred in it as
Donaka Mark.
If we want to analyze this graph database on movies, we can use Cypher. It uses
the following basic query elements:
1.4 Graph Databases 17

• MATCH: Specification of nodes and edges, as well as declaration of search

patterns
• WHERE: Conditions for filtering results
• RETURN: Specification of the desired search result, aggregated if necessary

For instance, the Cypher query for the year the movie “The Matrix” was released
would be:

MATCH (m: Movie {Title: "The Matrix"})

RETURN m.Year

The query sends out the variable m for the movie “The Matrix” to return the
movie’s year of release by m.Year. In Cypher, parentheses always indicate nodes,
i.e., (m: Movie) declares the control variable m for the MOVIE node. In addition to
control variables, individual attribute-value pairs can be included in curly brackets.
Since we are specifically interested in the movie “The Matrix,” we can add {Title:
“The Matrix”} to the node (m: Movie).
Queries regarding the relationships within the graph database are a bit more
complicated. Relationships between two arbitrary nodes (a) and (b) are expressed
in Cypher by the arrow symbol “->,” i.e., the path from (a) to (b) is declared as “(a) -
> (b).” If the specific relationship between (a) and (b) is of importance, the edge
[r] can be inserted in the middle of the arrow. The square brackets represent edges,
and r is our variable for relationships.
Now, if we want to find out who played Neo in “The Matrix,” we use the
following query to analyze the ACTED_IN path between ACTOR and MOVIE:

MATCH (a: Actor) –[: Acted_In {Role: "Neo"}] –>

(: Movie {Title: "The Matrix"}])
RETURN a.Name

Cypher will return the result Keanu Reeves. For a list of movie titles (m), actor
names (a), and respective roles (r), the query would have to be:

MATCH (a: Actor) –[r: Acted_In] –> (m: Movie)

RETURN m.Title, a.Name, r.Role

Since our example graph database only contains one actor and two movies, the
result would be the movie “Man of Tai Chi” with actor Keanu Reeves in the role of
Donaka Mark and the movie “The Matrix” with Keanu Reeves as Neo.
18 1 Database Management

In real life, however, such a graph database of actors, movies, and roles has
countless entries. A manageable query would therefore have to remain limited, e.g.,
to actor Keanu Reeves, and would then look like this:

MATCH (a: Actor) –[r: Acted_In] –> (m: Movie)

WHERE (a.Name = "Keanu Reeves")
RETURN m.Title, a.Name, r.Role

Similar to SQL, Cypher uses declarative queries where the user specifies the
desired properties of the result pattern (Cypher) or results table (SQL) and the
respective database management system then calculates the results. However,
analyzing relationship networks, using recursive search strategies, or analyzing
graph properties is hardly possible with SQL.
Graph databases are even more relationship-oriented than relational databases.
Both nodes and edges of the graph are independent data sets. This allows efficient
traversal of the graph for network-like information. However, there are applications
that focus on structured objects as a unit. Document databases are suitable for this
purpose, which will be described in the next section.

1.5 Document Databases

1.5.1 Document Model

As a second example of NoSQL databases, we introduce document databases here.

A document is a written record that describes a specific subject matter for which it
contains all relevant information. As an example of a document, an invoice (see
Fig. 1.12 to the left) describes information about customers, suppliers, dates, articles,
and prices.
A document database describes the entire facts of an invoice in a self-contained
data set that contains all information relevant to the facts. Such a complete data set is
called a document, analogous to a written record.

Digital Document
A digital document is a set of information that describes a subject matter as a closed
unit and is stored as a file in a computer system.

In contrast, as shown in the previous section, a graph database would use different
node and edge types. A separate data set would be stored for each node and for each
edge. The data would be divided in a network-like manner (cf. Fig. 1.12 to the right).
Data records in document databases have a structuring that divides the content
into recognizable subunits. Lists of field values can be nested in a tree-like manner.
For example, the invoice document in Fig. 1.12 contains an “Item” field. This
contains a list of items, each of which again has fields such as “Name” and
1.5 Document Databases 19

Fig. 1.12 Invoice data is stored in a self-contained manner in the document model

“Price” with corresponding values. More often than lists or arrays, the complex
object structure is used to organize documents. The JSON (JavaScript Object
Notation) format is a syntax for describing complex objects that is particularly
suitable for Web development in JavaScript (see Sect. 2.5.1).

1.5.2 Document-Oriented Database Language MQL

MongoDB Query Language (MQL) is an object-oriented language for interacting

with document databases to create, read, update, delete, and transform data. The
JavaScript-based language was originally developed for server-side Web
programming.
The database model of an MQL document database consists of collections of
structured digital documents. For example, in Fig. 1.12, there are five invoice
documents in the INVOICES collection. Because they are schema-free, the
documents in a collection can have any number of fields. Thus, new fields and
objects can be created very flexibly at any time. For example, for private persons, the
fields “First name” and “Last name” can be stored instead of the field “Company.”
As a rule, however, documents with predominantly identical fields are collected in
collections. Collections provide the following basic elements as methods in MQL:
20 1 Database Management

• find ( ) allows filtering a collection.

• insertOne ( ) adds data to a collection.
• updateOne ( ) allows to modify a collection.
• deleteOne ( ) deletes documents in a collection.

For example, if we want to display the invoices of the company “Miller Elektro”
in Fig. 1.12, we can use the following MQL query:

db.INVOICES.find ( {"Vendor.Company": "Miller Elektro"} )

This will make the database system return a list of invoices that match the filter
criterion. Each document is output in a complex object structure with a unique
identification key. This way, we get all the complete data for each invoice with
self-contained records.
In this code example, the constant “db” is an object that provides the functionality
of the database system. Collections of the database are accessible as child objects in
fields of the “db” object, e.g., db.INVOICES, providing methods such as find,
insertOne, updateOne, and deleteOne.
The query language MQL is structured with JSON. For example, the filter in the
find() method is passed as a parameter in JSON notation, which lists the filter criteria
as a field-value pair.
If we want to output a list of customers to whom the company “Miller Elektro”
has written an invoice, this is accomplished with a second argument:

db.INVOICES. find(
{"Vendor.Company": "Miller Elektro"},
{"customer.company": 1, _id: 0} )

The second list defines the projection with fields that are either included (value 1)
or excluded (value 0). Here, the field “Company” of the subobject “Customer” is
included in the result as an inclusion projection; the field _id is excluded. Thus, we
get a list of JSON documents containing only the values of the included fields:

{ customer: { company: "Mega IT" } }

{ customer: { company: "Bakery Becker" } }
{ customer: { company: "Sewing Studio Needle" } }
...
1.6 Organization of Data Management 21

Unlike SQL, MQL evolved in practice and is based on the JSON format, whose
creator says he did not invent it but “discovered” it because it already “existed in
nature.” Because of this organic development, many concepts of MQL appear
somewhat different from those of SQL, which have been theorized based on
mathematical principles.

1.6 Organization of Data Management

Many companies and organizations view their data as a vital resource, increasingly
joining in public information gathering (open data) in addition to maintaining their
own data. The continuous global increase of data volume and the growth of
information providers and their 24/7 services reinforce the importance of
Web-based data pools.
The necessity for current information based in the real world has a direct impact
on the conception of the field of IT. In many places, specific positions for data
management have been created for a more targeted approach to data-related tasks
and obligations. Proactive data management deals both strategically with informa-
tion gathering and utilization and operatively with the efficient provision and
analysis of current and consistent data.
Development and operation of data management incur high costs, while the
return is initially hard to measure. Flexible data architecture, non-contradictory
and easy-to-understand data description, clean and consistent databases, effective
security concepts, current information readiness, and other factors involved are hard
to assess and include in profitability considerations. Only the realization of the data’s
importance and longevity makes the necessary investments worthwhile for the
company.
For better comprehension of the term data management, we will look at the four
subfields: data architecture, data governance, data technology, and data utilization.
Figure 1.13 illustrates the objectives and tools of these four fields within data
management.
Data utilization enables the actual, profitable application of business data. A
specialized team of data scientists conducts business analytics, providing and
reporting on data analyses to management. They also support individual
departments, e.g., marketing, sales, customer service, etc., in generating specific
relevant insights from Big Data. Questions that arise in connection with data use are
the following:

• What purpose does the database serve?

• Which decisions are supported by which data, and how?
• Where does the data come from, and for what reason?
• What results are provided based on the data, and how are they presented?
• How can users interact with the data?
22 1 Database Management

Data Utilization Data Technology

► Use case ► Database Software

► Decision Support ► Integrated System
► Data Sources ► Data Input
► Data Visualization ► Data Processing
► User Interaction ► Performance

Data Administration Data Architecture

► Operational organization ► System Interfaces

► Data Access ► Data Modeling
► Database Security ► Database Schema

Fig. 1.13 The four cornerstones of data management

Employees in data architecture analyze, categorize, and structure the relevant

data, system components, and interfaces by a sophisticated methodology. In addition
to the assessment of data and information requirements, the major data classes and
their relationships with each other must be documented in data models of varying
specificity. These models, created from the abstraction of reality and matched to each
other, form the foundation of the database schemas. Data architecture answers the
following questions:

• What are the components, interfaces, and data flows of the database and informa-
tion systems?
• Which entities, relationships, and attributes are mapped for the use case?
• Which data structures and data types are used by the DBMS to organize the data?

Data administration aims for a unified coverage of the responsibilities in order to

ensure a cross-application use of the long-lived data. Today’s tendency toward
increased data security leads to a growing responsibility of data administrators for
security concepts and assigning permissions. For this purpose, the following points
are addressed from the data administration point of view:

• Who plans, develops, and operates the database and information systems using
what methods?
• Who has what access to the data?
• How are security, confidentiality, integrity, and availability requirements met?
Bibliography 23

Data technology specialists install, monitor, and reorganize databases and are in
charge of their multilayer security. Their field further includes technology manage-
ment and the need for the integration of new extensions and constant updates and
improvements of existing tools and methods. The data flows from and to the
database systems, and the user interfaces are also provided technologically. For
Big Data, it is of central importance that the speed of data processing is also
optimized for large data volumes. Thus, data engineering deals with the following
questions:

• Which SQL or NoSQL database software is used and for what reasons?
• How is the database system implemented and integrated?
• How is the data entered or migrated into the database?
• How is the data queried, manipulated, and transformed?
• How can the database system and queries be optimized in terms of volume and
speed?

Based on the characterization of data-related tasks and obligations, data manage-

ment can be defined as:

Data Management
Data management includes all operational, organizational, and technical aspects of
data usage, data architecture, data administration, and data technology that optimize
the deployment of data as a resource.

Data Management Plan

A planning document that outlines solutions for the use, architecture, technology,
and administration of data, and addresses corresponding issues, is called a data
management plan.
Such a plan is often prepared prior to implementing a database system. If all of the
questions listed above are answered, a data management system is anchored in a
comprehensive breadth of context and planned accordingly. Locally, however, some
questions are only answered iteratively during operation.

Bibliography
Celko, J.: Joe Celko’s Complete Guide to NoSQL – What every SQL professional needs to know
about nonrelational databases. Morgan Kaufmann (2014)
Connolly, T., Begg, C.: Database Systems – A Practical Approach to Design, Implementation, and
Management. Pearson (2015)
Coronel, C., Morris, S.: Database Systems – Design, Implementation, & Management. Cengage
Learning (2018)
Edlich, S., Friedland, A., Hampe, J., Brauer, B., Brückner, M.: NoSQL – Einstieg in die Welt
nichtrelationaler Web 2.0 Datenbanken. Carl Hanser Verlag (2011)
Elmasri, R., Navathe, S.: Fundamentals of Database Systems. Addison-Wesley (2022)
24 1 Database Management

Fasel, D., Meier, A. (eds.): Big Data – Grundlagen, Systeme und Nutzungspotenziale. Edition
HMD, Springer (2016)
Hoffer, J., Venkataraman, R.: Modern Database Management. Pearson (2019)
Kemper, A., Eikler, A.: Datenbanksysteme – Eine Einführung. DeGruyter (2015)
MongoDB, Inc.: MongoDB Documentation (2022)
Perkins, L., Redmond, E., Wilson, J.R.: Seven Databases in Seven Weeks: A Guide to Modern
Databases and the Nosql Movement, 2nd edn. O’Reilly UK Ltd., Raleigh, NC (2018)
Ploetz, A., Kandhare, D., Kadambi, S., Wu, X.: Seven NoSQL Database in a Week – Get Up and
Running with the Fundamentals and Functionalities of Seven of the Most Popular NoSQL
Databases. Packt Publishing (2018)
Saake, G., Sattler, K.-U., Heuer, A.: Datenbanken – Konzepte und Sprachen. mitp (2018)
Silberschatz, A., Korth, H., Sudarshan, S.: Database Systems Concepts. McGraw Hill (2019)
Steiner, R.: Grundkurs Relationale Datenbanken – Einführung in die Praxis der
Datenbankentwicklung für Ausbildung, Studium und IT-Beruf. Springer Vieweg (2021)
Ullman, J., Garcia-Molina, H., Widom, H.: Database Systems – The Complete Book. Pearson
(2013)
Database Modeling
2

2.1 From Requirements Analysis to Database

Data models provide a structured and formal description of the data and data
relationships required for an information system. Based on this, a database model
or schema defines the corresponding structuring of the database. When data is
needed for IT projects, such as the information about employees, departments, and
projects in Fig. 2.1, the necessary data categories and their relationships with each
other can be defined. The definition of those data categories, called entity sets, and
the determination of relationship sets are at this point done without considering the
kind of database management system (SQL or NoSQL) to be used for entering,
storing, and maintaining the data later. This is to ensure that the data and data
relationships will remain stable from the users’ perspective throughout the develop-
ment and expansion of information systems.
It takes three steps to set up a database structure: requirement analysis, conceptual
data modeling, and implementing database schemas by mapping the entity relation-
ship model to SQL or NoSQL databases.
The goal of requirement analysis (see point 1 in Fig. 2.1) is to find, in cooperation
with the user, the data required for the information system and their relationships to
each other including the quantity structure. This is vital for an early determination of
the system boundaries. The requirements catalog is prepared in an iterative process,
based on interviews, demand analyses, questionnaires, form compilations, etc. It
contains at least a verbal task description with clearly formulated objectives and a list
of relevant pieces of information (see the example in Fig. 2.1). The written descrip-
tion of data connections can be complemented by graphical illustrations or a
summarizing example. It is imperative that the requirement analysis puts the facts
necessary for the later development of a database in the language of the users.
Step 2 in Fig. 2.1 shows the conception of the entity-relationship model, which
contains both the required entity sets and the relevant relationship sets. Our model
depicts the entity sets as rectangles and the relationship sets as rhombi. Based on the
requirement catalog from step 1, the main entity sets are DEPARTMENT,

# The Author(s), under exclusive license to Springer Nature Switzerland AG 2023 25

M. Kaufmann, A. Meier, SQL and NoSQL Databases,
https://doi.org/10.1007/978-3-031-27908-9_2
26 2 Database Modeling

Order no. 113

1. Requirements analysis
Date: 07/14/2023
For project monitoring purposes, employees, work, and project
Goal
times should periodically be reported per department.

1. Employees report to departments, with each employee being assigned

to exactly one department.

2. Each project is centrally assigned a unique project number.

3. Employees can work on multiple projects simultaneously; the respective

percentages of their time are logged.

4. ...

2. Entity-relationship
DEPARTMENT model

Entity sets
Relationship sets
MEMBERSHIP

EMPLOYEE INVOLVED PROJECT

3a. Relational model 3b. Graph model

DEPARTMENT
EMPLOYEE

IS_MEMBER IS_INVOLVED
EMPLOYEE

DEPARTMENT PROJECT

PROJECT
3c. Document model

EMPLOYEE:
Name:
Place:
MEMBERSHIP
DEPARTMENT:
Name:
PROJECTS:
INVOLVED
Name:
Workload:
Name:
Workload:

Fig. 2.1 The three steps necessary for database modeling

2.1 From Requirements Analysis to Database 27

EMPLOYEE, and PROJECT.1 To record which departments the employees are

working in and which projects they are part of, the relationship sets MEMBERSHIP
and INVOLVED are established and graphically connected to the respective entity
sets. The entity-relationship model therefore allows for the structuring and graphic
representation of the facts gathered during data analysis. However, it should be noted
that the identification of entity and relationship sets, as well as the definition of the
relevant attributes, is not always a simple, clear-cut process. Rather, this design step
requires quite some experience and practice from the data architect.
Next, in step 3, the entity relationship model is mapped into a database schema,
with different rules for SQL and NoSQL databases. This can be, e.g., a relational
database schema (Fig. 2.1, 3a), a graph database schema (Fig. 2.1, 3b), or a
document database schema (Fig. 2.1, 3c).
Since relational database management systems allow only tables as objects, the
data records and their relationships can only be expressed in terms of tables and
columns. For that reason, there is one entity set table each for the entity sets
DEPARTMENT, EMPLOYEE, and PROJECT in Fig. 2.1, step 3a. In order to
represent the relationships in tables as well, separate tables have to be defined for
each relationship set. In our example, this results in the tables MEMBERSHIP and
INVOLVED. Such relationship set tables always contain the keys of the entity sets
affected by the relationship as foreign keys and potentially additional attributes of
the relationship.
In step 3b of Fig. 2.1, we see the depiction of an equivalent graph database. Each
entity set corresponds to a node in the graph, so we have the nodes DEPARTMENT,
EMPLOYEE, and PROJECT. The relationship sets MEMBERSHIP and
INVOLVED from the entity-relationship model are converted into edges in the
graph-based model. The relationship set MEMBERSHIP becomes a directed edge
type from the DEPARTMENT node to the EMPLOYEE node and is named
IS_MEMBER. Similarly, a directed edge type with the name IS_INVOLVED is
drawn from the EMPLOYEE to the PROJECT node types.
The mapping of the facts in document databases is shown in Fig. 2.1, 3c. Several
related entities are serialized in a unified document structure. For this purpose, the
entities are aggregated, i.e., nested. This implies an order of aggregation, which may
vary depending on the use case. In the example in the figure, there is a field
EMPLOYEE on the first level. This represents an employee object with fields
name and location. On the second level, there is on the one hand a field DEPART-
MENT, which embeds the corresponding department data per employee as a
subobject. On the other hand, a list of project information is stored per employee
in the PROJECTS field, including the workload, which is essential for reporting.
This is only a rough sketch of the process of data analysis, development of an
entity-relationship model, and definition of a relational or graph-based database
schema. The core insight is that a database design should be developed based on

1
The names of entity and relationship sets are spelled in capital letters, analogous to table, node, and
edge names.
Random documents with unrelated
content Scribd suggests to you:
 XX.

Het was twee uur.

Delphin had de kamers in het huis van den minister gearrangeerd naar den
smaak, die, zooals hij beweerde, op de Tuilerieën gedurende het tweede
keizerrijk mode was geweest.

In het midden van het vertrek stonden geene meubelen, zoodat men zich
daar ongedwongen kon bewegen; doch in alle hoeken half verscholen onder
de zware gordijnen, waren fauteuils en tabouretten geplaatst, waarom zich
hoogstens drie of vier personen konden groepeeren.

Het was hem door zijne vroolijke invallen en door zijn talent, om alles met
smaak en naar den zin van mevrouw in te richten, gelukt hare booze luim,
ten minste gedeeltelijk, te verdrijven, en tevens was de kamerheer al de
door hem gewenschte berichten, aangaande het plotselinge vertrek der door
de natuur zoo stiefmoederlijk bedeelde kinderen, te weten gekomen. In de
eetzaal stond eene zoogenaamde „koude tafel,” gedekt,—een uitgezocht
déjeuner met fijne wijnen en champagne. Het plan was, dat de gasten niet
op elkaar met het eten zouden wachten, ongedwongen moest het toegaan,
zoodat ieder die kwam zich dadelijk bedienen kon. Het moest op deze wijze
toegaan, want allen hadden geen tijd lang te blijven:—de meesten hadden
nog vóór de komst van den koning het een en ander in orde te brengen. Men
kon niet met zekerheid zeggen, wanneer de gastheer zou verschijnen, want
hij had nog veel werk voor de borst en daarbij was Daniel, vertelde
mevrouw op vertrouwelijken toon aan Delphin, zeer slecht gehumeurd.

In de salons zag men langzamerhand verschijnen: militairen in groot tenue,

heeren ambtenaren in uniform, de voornaamsten der geestelijkheid met
stijve, gepijpte kragen en ordeteekenen, verder twee of drie ministers en
eenige eerzuchtige advocaten, die zich op de eerste trede van de ladder
bevonden.
De groothandelaar Falck-Olsen trad in zijn nieuwe uniform van de „gele
vereeniging,” de salon binnen. „Ik heb de Champagne aan de achterdeur
laten bezorgen,” fluisterde hij mevrouw toe, terwijl hij haar de hand drukte.

Daarna zag hij links en rechts om zich heen, en aan ieder, dien hij
ontmoette, vroeg hij wanneer minister Bennecken zou komen. Eindelijk
stond hij vlak bij den kamerheer Delphin, die zijne fraaie uniform zeer
bewonderde.

„Gij ziet er uit als een zweedsch officier,” zeide de kamerheer tot hem.

De groothandelaar rammelde onder het gesprek telkens met zijnen sabel en

wierp ter sluiks eenen blik in den spiegel.

„Gij kunt niet half gelooven, beste kamerheer, in welke pijnlijke

verlegenheid ik geweest ben bij de keuze van een paard, want mijne
prachtige zwarte merrie is eigenlijk een koetspaard. Nu heb ik wel een
Isabella, een mooi dier met prachtige manen en zoo glad van huid en rond
van vormen, dat het een lust is het dier te zien—ik heb het van een
paardenopkooper van de Westkust gekocht—maar het ongeluk wil, dat het
dier een weinig klein is en—”

„Napoleon bereed altijd kleine paarden,” zeide Delphin.

„Werkelijk!” riep de heer Falck-Olsen verheugd uit, „en denk eens, de

kolonel zwoer bij hoog en bij laag, dat mijn Isabella te goed was voor het
gele corps.”

„Maar gij zult toch het mooie dier berijden,” vroeg Delphin op eenen toon,
alsof hij ’t een zaak van ’t grootste gewicht beschouwde.

„Ja, ik neem mijn Isabella,” antwoordde de groothandelaar op beslisten

toon.

Onder de laatst aangekomenen bevond zich de ambtman Hiorth van de

Westkust. Hij was kort geleden in de stad gekomen en het gerucht wilde,
dat hij den ouden Falbe zou vervangen, die afgetreden was, na den—zelfs
voor een noorsch minister—eerwaardigen ouderdom van 82 jaren te hebben
bereikt.

Hiorth gaf zijn genoegen te kennen den kamerheer Delphin te ontmoeten,

die in vroegere jaren bij hem als jong advocaat werkzaam was geweest, en
hij verzocht de kamerheer hem aan dezen en genen der meest invloedrijke
lieden voor te stellen. In vele jaren was hij niet in de hoofdstad geweest;
velen waren hem dus onbekend.

Intusschen was hij spoedig weer op hoogte, want voor het meerendeel
droegen de gasten nog die half Duitsche uit den Deenschen tijd ingevoerde
namen, die volgens een geheimzinnig erfelijk recht eenige vette landsposten
aan zich verbinden. Niet alleen schijnen deze heeren de namen en
betrekkingen hunner vaderen te hebben geërfd, maar zelfs in hun
voorkomen hebben zij iets behouden, dat aan den tijd van Frederik den
Zesde herinnert: hetzelfde regelmatige, wel gevormde profiel, hetzelfde
kleine ronde hoofd, denzelfden stijven hals en hetzelfde gelaat, door eenen
korten, stoppeligen baard omgeven, dat van voortdurende bescheidenheid
getuigt.

Naar Delphins plan had het gezelschap zich in de hoeken en bij de ramen in
kleine groepjes verdeeld, terwijl men midden in de vertrekken meest twee
aan twee ging, anderen waren nog om de tafel geschaard of met hunne
borden in de andere kamers verdwenen. Om een rijzig mager heer met een
langen grijzen baard, een Noorsch beeldhouwer, die zijn atelier in
Stockholm had, hadden zich ook vele gasten verzameld.

Naar men zeide, was hij te Christiania gekomen om gedurende de

aanwezigheid van den koning, de belangstelling voor een nationaal
monument, waarvan hij eene schets ontworpen had, op te wekken.

Het was eene groep, die de vereeniging tusschen Noorwegen en Zweden

moest voorstellen; het plan bestond, het monument op de Eidsvoldsmarkt
vlak voor het Storthinggebouw te plaatsen. Hij had de schets, verkleind en
in potlood bij zich, en liet die aan hen, die om hem heen stonden, zien.
De omstanders legden veel belangstelling aan den dag en prezen de schets
zeer, want allen waren genoeg met den loop der zaken bekend om te
begrijpen, dat, als men tot lid van het Comité werd benoemd, men zeker op
een ordeteeken kon rekenen.

De schets stelde Svea1 voor als eene zittende vrouwelijke gestalte; de eene
hand rustte op een zwaard, terwijl de andere arm om den hals van eenen
kleinen knaap, die naast haar stond, geslagen was.

De kunstenaar vertelde, dat volgens het oorspronkelijke plan de knaap op

de knieën van de vrouwelijke figuur had moeten zitten, maar, daar hij in
aanmerking had genomen, hoe licht geraakt de Noren van natuur zijn, had
hij den knaap naast haar geplaatst, zoodat iedereen dadelijk zien kon, dat de
figuren denzelfden rang innamen. Om dezelfde reden had hij den knaap
een’ grooten helm opgezet, die hem over de ooren zat, en een groot
slagzwaard rustte tegen zijnen schouder, hetgeen—half humoristisch—
moest uitdrukken, dat, zoo het noodig zijn mocht, de kleine knaap zich de
vijanden van het lijf zou kunnen houden.

Als een volleerd hoveling antwoordde de kunstenaar op al de indirecte

vragen, die hem aangaande de samenstelling van een comité werden
gedaan, dat de minister Bennecken aangeboden had, daarvoor te zorgen.

De kamerheer Delphin had den ambtman Hiorth aan een der voornaamste
predikanten uit de hoofdstad voorgesteld. Zij stonden bij een venster te
praten, maar, daar zij volstrekt niet met elkander bekend waren, liep het
gesprek over het verschil, dat er bestaat tusschen het leven in eene stad en
buiten, en over dergelijke algemeene onderwerpen.

Na een paar onbeduidende opmerkingen kreeg de ambtman gelegenheid te

zeggen: „Het verwondert mij dikwijls, dat er tegenwoordig zulke valsche,
scheeve voorstellingen over ons volk in de wereld in omloop zijn. Ik moet
er mij steeds over verbazen; want iemand in mijne betrekking, die altijd te
midden van het volk leeft, is meer dan iemand anders in staat over de
toestanden te oordeelen. Mijne dagelijksche bezigheden brengen mij
onophoudelijk met het zoogenaamde „Volk” in aanraking; ik spreek den
boer in zijne slechte en voorspoedige dagen, ik ben bekend met zijne goede,
zoowel als met zijne slechte eigenschappen.”

Hier viel zijn toehoorder hem haastig in de rede: „Gij denkt er juist over als
ik. Ik ben langer dan vijf jaar predikant in eene kleine gemeente op het land
geweest, en durf zeggen, ofschoon ik er mij in het minst niet op wil
beroemen, dat niet vele predikanten zooals ik in en met het volk hebben
geleefd, maar juist daarom schijnen mij die moderne, hoogdravende
phrasen, waarin men de boeren zoo ophemelt ….”

„Ja, niet waar,” zeide de ambtman tevreden: „deze beklagenswaardige

overschatting van het volk, is in den grond niets anders dan een dekmantel
voor verborgen eergierigheid ….”

„En ongeloof,” vulde de predikant aan. De beide heeren begrepen elkander

nu volkomen en zett’en het gesprek op een vertrouwelijken fluisterenden
toon voort.

De Redacteur Mortensen verscheen zeer laat. Hij behoorde tot de weinigen,

die nog geen ordelintje in het knoopsgat hadden. Aan de familiare wijze,
waarop hij dezen en genen groette, kon men evenwel zien, dat hij een man
was, die vasten grond onder de voeten had.

Hij was in werkelijkheid gedurende de laatste jaren, sedert hij de Redactie

van den „Waren Vriend des Volks,” op zich had genomen, een geheel ander
mensch geworden. Zijn linnen was nu altijd hagelwit en er lag in de wijze
waarop hij zich presenteerde die voorzichtige deftigheid, welke den
vertegenwoordiger der pers zoo goed staat.

Delphin nam hem scherp op en kwam tot de conclusie, dat mijnheer de

Redacteur eene geheime conferentie met den minister moest hebben gehad.

Dit was ook het geval geweest.

In het begin was de toon van den minister vrij scherp geweest; hij begreep
niet dat zulk een verzuim, de stukken in den chaos betreffende, had kunnen
plaats hebben; Mortensen nam de vrijheid den minister in de rede te vallen
met aan te merken:

„Ja die Mo, Excellentie, schijnt niet recht meer te weten, wat hij zeggen of
zwijgen moet; hij begint onbruikbaar, zoo niet lastig te worden. Hij gaat in
de bureau’s rond en vertelt allerlei rare geheimzinnige histories aangaande
eene zekere madam Gluncke, die ….”

„Hm ….” antwoordde de minister. „Ja gij hebt gelijk; reeds lang ben ik
ontevreden over hem, hij schijnt kindsch te worden.”

De minister sloeg nu een geheel anderen toon aan en toen Mortensen het
vertrek verliet, straalde zijn bolbleek gezicht van innige tevredenheid.

Er lag nog iets triomfeerends in zijne trekken, toen hij Delphin naderende,
vroeg: „Wilt gij zoo goed zijn mijnheer Delphin, mij aan den ambtman
Hiorth voor te stellen.”

„Neen,” antwoordde de kamerheer kortaf, terwijl hij voor den spiegel

staande, zijne Wasa-orde wat terecht schoof.

Mortensen beet zich van woede in de lip, doch zeide kalm: „De minister
heeft uitdrukkelijk zijnen wensch te kennen gegeven, dat ik u zulks zou
vragen.”

Delphin haalde de schouders op, en bracht Mortensen naar de plaats, waar

de ambtman Hiorth stond te praten.

„Mijnheer de ambtman! Ik heb het bevel ontvangen u den commies

Mortensen voor te stellen”; na deze woorden gezegd te hebben, verdween
hij dadelijk.—Den geheelen tijd had hij getracht Hilda te ontmoeten, in al
de kamers had hij haar gezocht, maar nergens was zij te vinden.

Mortensen zwoer in stilte zich bij gelegenheid op den kamerheer over deze
behandeling te zullen wreken. Hij verklaarde in een paar woorden aan den
ambtman Hiorth, wie hij eigenlijk was, waarop zich terstond een
vriendelijke plooi op diens gezicht vertoonde.
Geruimen tijd spraken zij met elkander, en Mortensen haalde een klein
notitieboek voor den dag, waarin hij eenige biografische détails, die den
ambtman hem meedeelde, opteekende. Het gesprek liep daarna over de
vragen van den dag, en de ambtman drukte zijne verontwaardiging zoowel
als zijne bekommering uit over de zware, moeielijke tijden, die men
beleefde.

De Redacteur antwoordde geruststellend:

„Och, zoo lang ons land zich mag verheugen een’ ambtenaarsstand te
bezitten als de onze ….”

„Ja, ja, op de predikanten en rechters kunnen wij ons geheel verlaten,” zeide
de ambtman, terwijl hij beproefde de deftige handbeweging, welke hij
Bennecken had afgezien, te maken.

„En met mannen aan het roer van den staat, als de minister Bennecken! o,
daar komt hij!…. welk een man! iets eerbiedwekkends omstraalt hem.”

„Vindt gij niet, ambtman, dat hij in het oog vallend op Goethe gelijkt.”

„Ja, werkelijk, werkelijk!” mompelde deze.

De minister was door eene deur, waarvoor eene portière hing,

binnengekomen, zoo dat het gezelschap niet dadelijk bemerkte, dat de
gastheer zich onder de gasten bewoog.

Hij was in zijne ministerieële uniform gekleed; een menigte sterren en

kruisen versierden de borst, den driekanten steek hield hij onder den arm en
de handschoenen had hij in de hand. Met de rechterhand groette hij naar
weerskanten zijne gasten en ging glimlachend en het hoofd een weinig naar
achteren geworpen, met deftigen tred door de salons.

Hij gaf de hand aan een’ zijner collega’s en fluisterde hem eenige woorden
in, welke de andere met een vertrouwelijk glimlachje beantwoordde. In de
onmiddellijke nabijheid van den minister werd het gesprek op gedempten
toon gevoerd, allen hadden, terwijl zij schijnbaar het gesprek voortzett’en,
slechts oog voor den minister.

De groothandelaar Falck-Olsen, die eigenlijk een kwartier geleden al in den

zadel had moeten zitten, naderde nu ook zijne Excellentie, niet als in
vroegere dagen, toen hij gaarne aan een ieder wilde toonen op welken
vertrouwelijken voet hij met Bennecken stond, neen, nu was op zijn gezicht
de grootste dienstvaardigheid en eerbied te lezen.

De minister boog zich tot hem en de heer Falck-Olsen fluisterde hem in ’t

oor: „Ik neem de Isabella.”

De voorname heer knikte toestemmend; als een koerier, die het hof met
gewichtige dépêches in den zak verlaat, ijlde de groothandelaar door de
salons; zijne sabel rinkelde en de spik-splinternieuwe uniform glinsterde in
de fraaie vertrekken, vriendelijk beschenen door de vroolijke Meizon.

Onderwijl zette de minister zijne wandeling voort, hier een vriendelijk

woord zeggende, elders de een of andere instructie gevende.

„Ik heb eenen president voor uw Comité gevonden,” zeide hij tot den
beeldhouwer, „den ambtman Hiorth.”

„Hm!…. de heer, die daar ginds bij het raam staat,” vroeg de kunstenaar,
die eenigszins door de keuze teleurgesteld was, maar als welopgevoed man
natuurlijk er niets van blijken liet, „maar wanneer ik vragen mag,
Excellentie, is deze heer niet een vreemdeling in de hoofdstad?”

„Hij zal dit niet lang meer blijven,” fluisterde de minister hem in.

„O, zoo …. ik begrijp!” antwoordde de andere en trok de wenkbrauwen

samen.

Nog bemerkte men, dat de minister ook de hand aan den ambtman Hiorth
reikte, welke eer hij, uitgenomen aan zijne collega’s, niemand der andere
gasten had bewezen; nu scheen het aan geenen twijfel meer onderhevig—
Hiorth zou tot minister benoemd worden, te eerder omdat de oude Falbe
zijn ontslag had aangevraagd.

„Wij staan er juist over te praten, Redacteur Mortensen en ik, hoe goed het
toch is, dat wij in deze moeielijke tijden ons onbepaald kunnen verlaten op
de predikanten en de rechterlijke macht.” De ambtman zeide dit met eenige
trotschheid.

„Of met andere woorden,” antwoordde de minister, „dat de godsdienst en de

gerechtigheid op onze zijde zijn.”

„Welk een man!” zeide op gedempten toon ambtman Hiorth, toen de

minister verder ging; onwillekeurig moest hij zijne uitdrukking met die van
den grooten staatsman vergelijken, en terwijl hij het raam uitzag, voegde hij
er bij: „och ja, veel wordt er toe vereischt zulk eene betrekking goed te
kunnen vervullen.”

„Sta mij toe, min ….. ambtman,” viel Mortensen hem op zeer eerbiedigen
toon in de rede, „sta mij toe u op eene goede oude uitdrukking opmerkzaam
te maken, namelijk, dat God met het ambt ook het talent en de kracht
verleent, om het goed te vervullen.”

„Dank, dank voor die woorden, waarde Redacteur,” riep de ambtman uit, en
hij drukte hem met warmte de hand; „ja, gij hebt gelijk, alle kracht komt
van boven,” en hij sloeg zijne oogen naar den helderen blauwen lentehemel,
die zich boven de daken welfde.

Nu begonnen de jonge ambtenaars, Hiorth en Bennecken, de

champagnekurken te laten knallen: hun was op dezen gewichtigen dag
opgedragen voor den wijn te zorgen.

De gasten gingen terug naar de eetzaal, waar de minister langzamerhand de

voornaamste van hen aan het boveneinde van de tafel verzamelde. Eene
plechtige stilte ontstond toen hij zijn glas ophief en aldus begon:

„Mijne heeren! wanneer ik mijnen blik over deze vergadering laat gaan, zoo
rijst bij mij onwillekeurig de vraag op: wat is het eigenlijk, dat ons allen zoo
vast samenbindt? Het is de gemeenschappelijke arbeid, de
gemeenschappelijke gehechtheid voor onzen verheven monarch!”

Mortensen, die achter een venstergordijn aanteekeningen maakte, moest

even lachen. Hij dacht aan de rede, die hij in deze zelfde zaal en over
hetzelfde onderwerp had gehouden, doch voor een ander publiek.

Vandaag nam de rede van den minister eene hoogere vlucht dan gewoonlijk,
inzonderheid schreef Mortensen zeer nauwkeurig het slot op.

„Ja, mijne heeren! Zooveel wordt er in onze dagen gesproken, dat de tijd,
dien wij beleven, een tijd van werken is; maar slechts weinigen zijn er—en
ik betreur zeer dat het zoo is—slechts weinigen zijn er, zeg ik, die recht
begrijpen, wat de ware arbeid is en wie eigenlijk de ware arbeiders in het
land zijn;…. Het zijn …. (de spreker zag rond) die kring van mannen, die de
orde hooger schatten, dan hun eigen voordeel; die trouw en gehoorzaam
verkleefd blijven aan de onomstootelijke waarheden, die ons door onze
vaderen in hunne staatsinstellingen en in hun vroom geloof zijn
nagelaten,…. die de diep gewortelde overtuiging hebben, dat hetgeen in een
tijd van oplossing en verdeeldheid een’ staat te zamen houdt, en eenen
sterken band bindt om het beste wat de natie bezit, uitgaat van en zich
concentreert in den heiligen persoon van den vorst. Mijne heeren! God
beware Zijne Majesteit, onzen geëerbiedigden Koning!”

„Leve de Koning!” gilde de overste kolonel-luitenant Grobs, en hierop

volgde een drievoudig hoera, dat de ruiten er van rinkelden; zelfs de meest
stijve bureaulisten schreeuwden, dat zij er blauw van zagen, terwijl zij
elkander zijdelings aankeken om te zien of ieder zijnen plicht deed.

Toen de stilte wat hersteld was, kwam de bediende van den minister haastig
binnenloopen, en met eene diepe buiging overhandigde hij een telegram op
een zilveren presenteerblaadje.

De minister opende en las de dépêche; de grootste stilte heerschte in de

zaal. Niemand van het gezelschap durfde bijna ademhalen.
„Mijne heeren! binnen een half uur kunnen wij den Koninklijken extratrein
met den Koning verwachten.”

Eene algemeene beweging ontstond: de minister hief even de hand op—

weder werd het doodstil.

„Mijne heeren!” zeide hij op plechtigen toon, „ieder op zijnen post. Het
oogenblik is ernstig; Zijne Majesteit verwacht, dat ieder zijnen plicht doe!”

Na deze woorden geuit te hebben, groette hij het gezelschap vluchtig, gaf
den ambtman Hiorth een teeken hem te volgen, en verdween met dezen
door de kleine deur, waarvan de portière onhoorbaar toeviel.

In geestdriftvolle stemming namen de gasten afscheid, en Mortensen

schreef in zijn notitieboekje: Het was een van deze merkwaardige nooit te
vergeten oogenblikken, in welke men als het ware den polsslag der
wereldgeschiedenis voelt.

Mevrouw Bennecken had reeds vroeger de gasten verlaten. Al de

gemoedsbewegingen, gedurende den ganschen dag ondervonden, hadden
haar zoo geschokt, dat zij zich gekleed op haar bed had geworpen, waarop
zij in hevig snikken was uitgebarsten.

In de salons wandelde Delphin eenzaam heen en weer. Hij behoefde eerst

tegen het souper op het slot te verschijnen, en het was hem onmogelijk het
huis te verlaten zonder Hilda te hebben ontmoet. De bedienden namen de
tafel af, dronken den nog in de glazen en flesschen aanwezige champagne
en waren zeer vroolijk. Delphin kon dus onmogelijk langer in de eetzaal en
het aangrenzend vertrek blijven, en trok zich in de verst afgelegen kamer
terug ontevreden op zich zelf, weifelende wat hem te doen stond, maar
voelende dat het hem niet mogelijk was heen te gaan, zonder haar
gesproken te hebben. Eindelijk riep hij een der dienstmeisjes en vroeg, waar
juffrouw Hilda was.

„Juffrouw Hilda is op hare kamer bezig met pakken. Weet u niet, dat de
juffrouw van avond naar Amerika vertrekt,” vroeg zij en hare mooie oogen
hadden van de Champagne een nog helderder glans gekregen.
Delphin, die door deze woorden onaangenaam getroffen werd, zeide kortaf:

„Vraag juffrouw Bennecken uit mijnen naam, of zij de goedheid wil hebben
een oogenblik hier te komen; ik zou haar gaarne even willen spreken.”

Toen het dienstmeisje was weggegaan, bleef hij verschrikt voor den spiegel
staan. Wat had hij gedaan?

Wat wilde hij eigenlijk van haar? Was hij niet te ver gegaan? hoe zou hij er
zich weer uithelpen? En wenschte hij dit niet het meest?

Na verloop van eenige minuten kwam Hilda binnen. Aan hare oogen kon
men zien, dat zij geschreid had, maar toch lag er over haar gelaat eene
bijzondere kalmte. Delphin bemerkte dit dadelijk.

„Arme mama!” zeide zij, terwijl zij hem beide handen reikte; „het is haar
zoo zwaar gevallen zich met de gedachte vertrouwd te maken, dat Johan en
ik zulk eene verre reis gaan ondernemen. Ja, ik zelf heb moeite te gelooven,
dat zij door zal gaan.”

Delphin vergat haar te antwoorden, zoo veranderd kwam zij hem voor. Hare
verlegenheid, bijna zou men het hebben kunnen noemen, schuwheid was
geheel verdwenen. In haar eenvoudig toilet zag zij er zoo vastberaden en
reisvaardig uit, en er was zoo iets zekers in hare stem en in geheel haar
voorkomen, dat het hem niet gelukken wilde den half schertsenden, half
beschermenden toon, waarop hij gewoonlijk met haar sprak, aan te slaan.

Meer door de toon zijner stem, dan door de woorden, die hij sprak, keek
Hilda op. Hunne oogen ontmoetten elkander voor eene seconde en er
ontstond eene pauze.

„Er is niets, dat u terughoudt niet waar?” vroeg hij op bitteren toon.

„O ja, dat weet gij heel goed,” luidde haar antwoord en hare oogen vulden
zich met tranen.
Hij zag haar van ter zijde aan; zoo als zij daar stond het hoofd wat voorover
gebogen, terwijl zij zenuwachtig met haren zakdoek speelde, vroeg hij zich
af, of zij dan werkelijk zoo leelijk was?

„En er is niets, dat u terughoudt?” Hij wist niet, dat hij dit reeds had
gevraagd.

„Waarom wilt gij mij het afscheid zwaarder maken, dan het reeds is,” vroeg
zij bijna onhoorbaar en begon te schreien. George Delphin ging het vertrek
een paar maal op en neer. Hij gevoelde, dat het leven hem eene goede kans
bood en dat het nu voor het laatst zou zijn. Al het goede dat in hem was,
trachtte hij te verzamelen, maar toen hij voor haar stond, hief zij even het
hoofd op, en zeide:

„Neen, ik wil niet meer schreien. Ik voel, dat een gelukkiger leven mij daar
wacht, dan mij ooit hier ten deel zou kunnen vallen. Vaarwel kamerheer—
hartelijk zeg ik u dank voor uwe vriendschap.”

Zij reikte hem de hand en keek hem met de trouwe gazellen-oogen, die vol
tranen stonden, moedig aan. Op dit laatste oogenblik zag hij dat zij schoon
was—maar toen was het te laat. Zij verliet het vertrek en liet de deur half
open. Het leven, dat de bedienden in de zaal maakten, drong weer tot hem
door. Hij stond voor een oogenblik roerloos, nam toen zijnen hoed en
verliet het huis. Op de trap werd hij ingehaald door den jongen Hiorth en
door Bennecken, die juist van den zolder kwamen. Met levensgevaar
hadden zij eene vlag uit het dakvenster gestoken.

1 Zweden. ↑
 XXI.

Het kostte heel wat tijd, eer Njaedel en Sechus het hospitaal, waar Christine
zich bevond, vonden en hadden zij niet bij toeval den politie-agent Knudsen
naar den weg gevraagd, dan had het kunnen gebeuren, dat zij onverrichter
zake aan boord hadden moeten gaan, of wel tot laat in den avond de stad in
alle richtingen hadden moeten doorkruisen. Het was reeds bijna drie uur en
iedereen stroomde naar de Karel-Johanstraat om den optocht te zien, zoodat
niemand tijd had te blijven staan om inlichtingen te geven; de politie-agent
Knudsen evenwel, die gelukkig zijnen proeftijd had doorstaan, wees hun,
toen hij hoorde, wie zij zochten, den weg en zoo kwamen zij aan het
hospitaal.

In de poort ontmoetten zij eene der verpleegsters, die naar de stad wilde
gaan. De opperloods nam zijne pelsmuts af en zeide: „Wij komen hier
zekere madam Christine Mo bezoeken.”

„Zij is van nacht gestorven,” antwoordde zij gejaagd: zij had haast.

„Gaat die gang in de tweede deur links, zij zijn juist met haar bezig.”
Schielijk liep zij verder en deed de poort achter zich dicht.

„Nu, nu, Njaedel, dat is misschien maar het best voor haar,” zeide de
opperloods om hem wat te troosten, „kom meê, wij hebben hier niets meer
te doen.”

„Ik wil haar lijk zien,” antwoordde Njaedel, en liep de gang in.

Vóór de deur, die de ziekeverpleegster had aangewezen, bleven zij staan; de

deur stond aan, en zij hoorden in het vertrek luid spreken. De opperloods
stiet de deur open, Njaedel en hij traden binnen.

Dicht bij het raam stonden eenige jonge studenten over iets wits, dat op de
tafel lag, heengebogen. Een klein man, met grijs haar en in zijne
hemdsmouwen stond het dichtst van allen bij dit witte voorwerp, terwijl
men eenen blanken voet tusschen twee der omstanders zag uitsteken.

„Nooit heb ik het zoo spoedig zien afloopen,” zeide dokter Rohde, tot een
der professoren, die hij had uitgenoodigd bij de ontleding tegenwoordig te
zijn. Johan Bennecken had uitdrukkelijk verboden het lijk naar de
ontleedkamer in de universiteit te brengen.

„En zij was met dien schurk van een Mo getrouwd?” vroeg de professor,
„hoe gaat het met hem?”

„De ziekte is naar binnen geslagen en de hersens zijn aangedaan. Wat wilt
gij?” vroeg de dokter plotseling, toen hij de twee mannen in de deur zag
staan.

„Hier is haar vader,” zeide de opperloods op Njaedel wijzende, „die gaarne

haar lijk wilde zien.”

„Neen, neen, beste vriend, ’t is beter dat gij zulks niet doet.”

Maar Njaedel kwam dichter bij de tafel; de jonge studenten maakten voor
hem plaats, en de professor gaf aan een der studenten een teeken een laken
over haar te werpen. Door de haast waarmede dit geschiedde werd het lijk
slechts ten halve bedekt; het was zoo uitgeteerd, dat het slechts vel en been
leek. Het dikke roode haar hing verward over het voorhoofd, de wangen
waren geheel ingevallen; zij zag er uit als eene oude vrouw.

„Dat is zij niet!” fluisterde de opperloods Njaedel in.

Maar toen streek Njaedel het haar van zijne gestorven dochter een weinig
op zijde en legde zijnen vinger op het litteeken, dat zij aan een der slapen
had.

„Kom, Njaedel, nu moesten wij maar gaan.”

De opperloods was doodsbleek. Njaedel zag rond en toen hij den indruk
kreeg, dat al deze welgekleede heeren belangstelling in zijne dochter
hadden getoond, reikte hij hun één voor één zijne hand. Toen hij echter bij
den professor kwam, week deze eene schrede achteruit:.. „Neen, neen, beste
man …. ik kan …. het is mij onmogelijk u de hand te reiken.”

Nu eerst zag Njaedel het blanke mes in zijne hand. Op dit gezicht rilde hij
en hij verliet met den opperloods dadelijk het vertrek.

Toen zij weer op straat stonden, zag Sechus Njaedel uitvorschend aan; hij
bemerkte dat deze de vuisten balde, en dat zijne tanden knarsend tegen
elkaar sloegen.

„Hij zal mij daar rekenschap van moeten geven, Anders,” mompelde
Njaedel.

„Och,” zeide de opperloods ietwat bang, „laat je aan Anders niet meer
gelegen liggen. Wij reizen nu ver weg, laten wij eerst zien, wat eten te
krijgen, want ik heb honger als een wolf.”

Maar Njaedel was niet van zijn plan af te brengen; de opperloods wilde
echter niet naar den weg vragen en zoo moest Njaedel zulks zelf doen; de
politie-agent, tot wien hij zich wendde, zeide hem, waar de minister
Bennecken woonde.

Eindelijk stonden zij vóór het huis.

Een vreeselijke strijd had er in Njaedel’s binnenste plaats. Hij kon niet
gelooven, dat zijn broeder de schuld van al die ellende was, en toch ook de
gedachte niet van zich zetten, dat zulks wel het geval was. Maar in toorn
ontstak hij niet, neen, eene diepe smart drukte hem ter neer, hij gevoelde er
behoefte aan zijnen broeder te zien: in zijn hart hoopte hij nog altijd, dat
deze misschien zich van die schuld zou kunnen vrijspreken.

Toen zij een paar treden waren afgegaan, zeide de opperloods: „Eéne zaak
moet gij mij beloven Njaedel, dat gij de hand niet aan hem zult slaan, denk
er aan dat hij je broeder is.”

„Daar kunt gij u op verlaten,” antwoordde Njaedel.

Anders was juist bezig zich te scheren.

Hij had het spiegeltje aan het vensterkozijn gehangen, zoodat het volle
daglicht, dat van de straat door het raam viel, hem bescheen. Met eenen
kant was hij klaar, maar de andere kant van zijn gezicht was nog ingezeept.
Toen hij zag, wie binnen kwamen, legde hij het scheermes uit de hand, en
een krampachtige trek verwrong zijn gezicht; spoedig echter herstelde hij
zich en de half idiote glimlach, die hem den laatsten tijd eigen was
geworden, vertoonde zich.

Hij stak zijnen broeder de hand toe. „Zoo ben je eindelijk gekomen
Njaedel …. daar hebt ge goed aan gedaan.”

„Anders …. Anders!” riep Njaedel uit en met gebalde vuisten stond hij
dreigend voor hem.

„Wat heb je Christine aangedaan?”

Toen hij deze krachtvolle stem hoorde, scheen Anders als uit eene
verdooving te ontwaken. Van schrik kromp hij ineen en vluchtte in den
versten hoek van het vertrek. Zijn gezicht was bijna aschgrauw, toen hij die
dreigende vuisten aanstaarde.

Langzamerhand gelukte het hem met de grootste inspanning zijne zwakke

hersens tot denken te dwingen. De diepe vouwen, ontstaan door den
valschen glimlach, die hem zoo lang eigen was geweest, legden zich
opnieuw om den mond, en hij zeide op klagenden toon:

„Dat je het over je hart hebt kunnen krijgen Njaedel, zóó tegen je broer te
zijn, die altijd zoo zwak en ziekelijk is geweest. Weet gij niet meer, hoe wij
voor moeder heideplantjes gingen plukken, daar op de hoogte?”

Njaedels armen vielen slap langs zijn lichaam.

Welke herinneringen bracht die zachte, klagende stem hem voor den geest,
dat geluid uit zijne kinderjaren, die stem van den broeder, dien hij zoo had
liefgehad!
„En weet je nog, wat moeder altijd zei,” ging Anders voort, terwijl hij zijn
broeder geen oogenblik uit het oog verloor; „moeder zei altijd: jij Njaedel
bent een groote slungel, zei zij, maar Anders is fijn en glad als een aal.”

Njaedel knikte toestemmend. Anders had gelijk.

En zijne moeder, en de hut daar ginds in de bergen, en de hoogte met de

heideplantjes, die in den zonneschijn zulk een’ heerlijken geur
verspreidden, alles stond op eens zoo klaar vóór hem; en te midden van dit
alles zag hij zijn broertje, bleek, zwak, hulpbehoevend, die door hem over
gevaarlijke plaatsen gedragen moest worden.

En al, wat tusschen dat verleden en dit tegenwoordige lag, smolt weg als
sneeuw voor de warme lentezon,—hij werd weer een kind, een groote,
linksche, goedhartige jongen, zooals hij altijd was geweest, en alle toorn
was in hem gebluscht, en toen hij wegging zeide hij slechts: „Anders …..
Anders ….. dat had je niet moeten doen!”

Toen zij in de poort waren, zeide Sechus:

„’t Is maar goed, dat gij de hand niet aan hem geslagen hebt, gij hadt hem
als een suikerkrakeling aan stukken kunnen breken.”

Njaedel’s krachten waren gebroken, hij leunde tegen eenen muur en snikte
luid.

De opperloods liet hem zoo lang weenen als hij dacht, dat noodig was;
daarna trok hij hem zacht bij den arm mee, en Njaedel volgde gedwee als
een lam. Eindelijk traden zij bij een restaurant binnen. De opperloods, die te
Petersburg en te Kopenhagen was geweest, vond zich hier spoedig te huis.
Hij bestelde twee portiën beefsteak en eene flesch bier. Juist toen zij aan de
gedekte tafel wilden gaan plaats nemen, dreunde het huis van de
kanonschoten.

„De koning is aangekomen!” riep het meisje, dat bediende1. Zij was in zeer
slechten luim, omdat zij die twee boeren moest bedienen in plaats van
eventjes den optocht te zien.
1 In Scandinavië heeft men in vele restaurants geene kellners, maar jonge meisjes
bedienen de gasten: vooral is zulks het geval in kleinere hotels. (Vert.) ↑