Demo Data from EDBT 2026 / reviewers in the wild / expert
Alexander Tekleab
dblp:228/6030
· DBLP profile ↗
2ranked-venue papers
0as first author
0since 2021 · last 2018
—ORCID · none
Domains — the database's venue-derived domains; a paper can count in several
Databases, data management, data science and information retrieval · 2
Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.
| Databases, data mining, and information retrieval
2 papers |
Database system architecture and tuning · 56% Data integration and cleaning · 44% | |
| Software engineering, system software, and programming languages
2 papers |
Software maintenance and evolution · 100% |
Topics — the 2 heaviest of 3, each with the papers that count most for it
| Topic | Weight | Papers | Last | Evidence papers |
|---|---|---|---|---|
Software maintenance and evolution › software evolution
schema evolution |
0.7 | 2 | 2018 | In for a Surprise When Migrating NoSQL Data · ICDE 2018 Curating Variational Data in Application Development · ICDE 2018 |
Data integration and cleaning
schema mapping |
0.3 | 1 | 2018 | Curating Variational Data in Application Development · ICDE 2018 |
Methods — techniques the papers use, named apart from their topics
query rewriting · 0.7data migration · 0.7composite operation caching · 0.7
| Year | Publication | Venue | Position |
|---|---|---|---|
| 2018 | Curating Variational Data in Application DevelopmentabstractBuilding applications for processing data lakes is a software engineering challenge. We present Darwin, a middleware for applications that operate on variational data. This concerns data with heterogeneous structure, usually stored within a schema-flexible NoSQL database. Darwin assists application developers in essential data and schema curation tasks: Upon request, Darwin extracts a schema description, discovers the history of schema versions, and proposes mappings between these versions. Users of Darwin may interactively choose which mappings are most realistic. Darwin is further capable of rewriting queries at runtime, to ensure that queries also comply with legacy data. Alternatively, Darwin can migrate legacy data to reduce the structural heterogeneity. Using Darwin, developers may thus evolve their data in sync with their code. In our hands-on demo, we curate synthetic as well as real-life datasets. Uta Störl, Daniel Müller 0004, Alexander Tekleab, Stephane Tolale, Julian Stenzel, Meike Klettke, Stefanie Scherzinger |
ICDE | 3 |
| 2018 | In for a Surprise When Migrating NoSQL DataabstractSchema-flexible NoSQL data stores lend themselves nicely for storing versioned data, a product of schema evolution. In this lightning talk, we apply pending schema changes to records that have been persisted several schema versions back. We present first experiments with MongoDB and Cassandra, where we explore the trade-off between applying chains of pending changes stepwise (one after the other), and as composite operations. Contrary to intuition, composite migration is not necessarily faster. The culprit is the computational overhead for deriving the compositions. However, caching composition formulae achieves a speed up: For Cassandra, we can cut the runtime by nearly 80%. Surprisingly, the relative speedup seems to be system-dependent. Our take away message is that in applying pending schema changes in NoSQL data stores, we need to base our design decisions on experimental evidence rather than on intuition alone. Uta Störl, Alexander Tekleab, Meike Klettke, Stefanie Scherzinger |
ICDE | 2 |