E XTENDING G OU DA : G ENERATION OF U NIVERSAL DATASETS WITH ( AND WITHOUT ) E RRORS FOR DATA Q UALITY B ENCHMARKING Valerie Restat* 1 , 1
André Conrad1 ,
Kevin M. Kramer1 , and
Uta Störl1
Faculty of Mathematics and Computer Science, FernUniversität in Hagen, Hagen, Germany
arXiv:2607.20165v1 [cs.DB] 22 Jul 2026
A BSTRACT Synthetic data is extremely important in areas such as data quality, data cleaning, and machine learning. It enables the analysis of use cases in which real data is insufficient, unavailable, or distorted. However, generating synthetic data also presents challenges: The data must be as realistic as possible, but at the same time cover edge cases. It must be possible to insert controlled errors, and at the same time, an error-free version of the data is usually required. Additionally, it is necessary to consider numerous data formats, such as tabular data, but also NoSQL data models. To this end, we present our data generator GouDa. GouDa precisely meets these requirements – it is suitable for different data formats, enables the controlled insertion of errors, and generates ground truth. A wide range of different generation functions and the option to add your own lists of possible attribute values allow the generation of realistic data that covers many different use cases.
1
Introduction
Data is a central concern of many business and scientific problems. But data is often not available in sufficient quality. Poor data quality can lead to wrong decisions and customer frustration, resulting in significant additional costs [EN25]. Industry studies often estimate that the costs resulting from poor data quality are in the millions [Res23]. To ensure high data quality, data cleaning is an important and necessary step. At the same time, data cleaning still requires a great deal of manual effort and is one of the most time-consuming tasks for data scientists [MA20]. For this reason, there has been extensive development in the fields of data cleaning algorithms and tools [BKY19]. Test data is required to evaluate new approaches and compare them with existing solutions. While real data is important for covering real scenarios, synthetic data is also highly significant for many reasons. These include privacy (especially in the health care domain), security and availability (some data cannot be accessed, or their retrieval is very time-consuming) [MAK+ 23, EVT22]. Moreover, real data is often insufficient to cover all possible scenarios, such as certain distributions or error types. Synthetic data can be used to address specific test cases and approaches for many different domains. Thus, generating synthetic data is quite important for researchers and business developers [EVT22]. In addition, common real-world datasets used in data quality research are already known to LLMs. Therefore, new data is necessary for a fair comparison of new methods. In this context, the importance of synthetic data is also increasing. [Abe25] As a contribution to this, we have developed GouDa, a tool for the automated generation of data sets with the possibility to include specific error types. We first introduced GouDa in a workshop paper with the title GouDa – Generation of universal Data Sets: Improving Analysis and Evaluation of Data Preparation Pipelines [RBCS22]. This article is an extended version of this paper. The present version is more comprehensive with a stronger focus on data generation, errors, and data quality. In addition, we have further developed GouDa since the last publication to GouDa 2.0, making it more user-friendly and easier to create data sets.
∗
Email address of the corresponding author: [email protected]
Extending GouDa: Generation of Universal Datasets with (and without) Errors for Data Quality Benchmarking
In summary, our contribution is as follows: • With GouDa 2.0, we provide a powerful data generator for synthetic data. • A graphical user interface (GUI) simplifies data generation. • Custom lists with possible attribute values enable the generation of data that is as realistic as possible. • GouDa offers the option of inserting controlled errors into the data and generating both the erroneous and the clean data. • With GouDa, both tabular and semi-structured data (for NoSQL data support) can be generated. • GouDa enables the creation of multiple entity types and the realization of complex relationships between them. • By using GouDa schema files, data can be generated in a reproducible manner. GouDa thus offers the possibility to generate flexible and reproducible data sets with and without errors. In this way, we aim to contribute to a common benchmark with standardized data sets for reproducible data quality research. In the following, we will go into more detail on the above points. The paper is structured as follows: Section 2 presents related work. Section 3 provides a detailed presentation of GouDa, including data generation, error types, architecture, and usage. In Section 4, we use an example to show how real data sets can be simulated. Section 5 summarizes the paper and provides an outlook on future work.
2
Related Work
Many test data generators exist, for example [GA14, PSH17, CAS+ 18, JS20, jF26], in both academic and commercial contexts. However, these generators focus on other areas, like software testing or SQL queries. The functionality to generate defined data errors with defined error rates is not provided. Arocena et al. [AGM+ 15] developed a tool for generating data sets with defined errors – BART (Benchmarking Algorithms for data Repairing and Translation). With this tool, errors are inserted into clean databases that are already in place, thus focusing on constraint-induced errors. In addition, a limited selection of other data errors can be inserted (typos, duplicates, bogus or null values, and outliers). BART requires a relational database schema with unique tuple identifiers and therefore does not support other database types, such as NoSQL databases. Another tool to obtain data as realistic as possible, is tab_err [JJCB25]. It can be used to insert errors into existing data. Various error types are available, such as missing values, outliers, typos, wrong units, and more. However, as with BART, tab_err is limited to tabular data. An existing data set is always required. One way to generate data for NoSQL databases is offered by Deimos [CRM20]. Deimos is a model-based language developed to generate synthetic data from NoSQL schemas. It supports the variability of NoSQL data, such as structural variations, aggregations, and references with referential integrity. It also offers the option of inserting errors into the data. However, only a few types of error are supported, such as missing values, incorrect data types, and duplicates. Synthetic data can be generated, but it is also possible to reuse parts of existing data sets. Unfortunately, no publicly available code could be found. With GouDa, we present the only data generator that • does not require existing data sets, • still generates data as realistic as possible, • supports a wide range of error types, • and can generate both tabular data and data for NoSQL databases.
3
GouDa
Unlike BART [AGM+ 15] and tab_err [JJCB25], GouDa does not need existing data. Instead, we create new JSON data sets and thus achieve a high flexibility. The basis for GouDa is the data generator implemented as part of the EvoBench project [CMK+ 21]. This data generator is based on the publicly available library json-data-generator2 . This library can be extended by generators. For example, functionality to define relations between different entity types was added as part of the EvoBench project [CMK+ 21]. As part of the GouDa project, the ability to generate errors was added. 2
https://github.com/vincentrussell/json-data-generator/tree/json-data-generator-1.12
2
Extending GouDa: Generation of Universal Datasets with (and without) Errors for Data Quality Benchmarking
After the publication of the first version [RBCS22], we further developed GouDa. As part of this process, a graphical user interface (GUI) was implemented. This simplifies data generation. Also, an abstract data model was developed. It represents the JSON data transmitted by the GUI as Java objects. This allows for easier extensibility and validation. The generation of multi data sets (multiple entity types) has also been improved, so that more complex relationship types are now possible. In the further course of the chapter, we’ll first describe how GouDa can be used to generate data. Then we’ll take a closer look at the types of errors it supports. After that, we’ll introduce the architecture and go over the usage of GouDa. 3.1
Data Generation
The basis for data generation is provided by GouDa Schema Definitions (GSD). These are templates represented in JSON format. By using the JSON format, not only relational data but also nested data is supported. In a GSD, the structure of the JSON data to be generated and the respective values are defined. Moreover, relationships can be specified in different distributions and the number of objects to be created. Internal and external references allow values from other fields to be reused. To generate data, values can be specified either statically or dynamically using GouDas generator functions. These can be divided into three categories: plain generators, dictionary generators, and error generators. Plain generators convert input parameters into output parameters using Java functions. An example is the generator to create random doubles: double(1.00, 99.99, "%.2f")
Here, random doubles are generated, in the range from [1.00, 99.99), with two decimal places. Dictionary generators choose random values from a dictionary, which is usually provided as a text file: brands()
This function generates brand names. The corresponding names are taken from a text file. If necessary, custom lists and generators can be added here. This makes GouDa easily extendable and flexible in use. Error generators can be used to insert controlled errors. The corresponding error types (see Section 3.2) and rates are configurable: error("MISSINGVALUE", 10, brands())
Here, the function from the previous example – brands() – is used to create brand names. Then, 10% of the names are removed, generating a data set with errors. In addition, a clean data set is generated for each data set with errors (for example including the missing brand names). The GUI simplifies data creation because all available generators are displayed in a drop-down menu. You can assign a name to a field, select a generator, and optionally add errors. If multiple entity types are created, there is an extra view for relationships. Here you can select the type of relationship to be used. The following relationship types are possible: • One-To-One • One-To-Many • Many-To-Many Furthermore, the distribution can be determined. The following options are available for this purpose: • Uniform • PoissonMax • GaussianMinMax • BetaMax • Binomial By default, the data is generated in the main memory and then stored on the hard disk. However, it is also possible to generate the data directly in a MongoDB database. Support for other databases will follow in future versions. In summary, data generation with GouDa offers the following key benefits: 3
Extending GouDa: Generation of Universal Datasets with (and without) Errors for Data Quality Benchmarking
• Realistic: For better applicability, synthetic data sets should be as realistic as possible. To achieve this, the opportunity to include lists with possible attribute values is provided. Different lists with realistic names, words or addresses are already included. Your own new lists can also be added. Our goal is to obtain data sets that are as close as possible to real data sets while still benefiting from the advantages of synthetic data generation. • Portable: As mentioned, the data sets are generated in JSON format. This can be used for different systems. This has the advantage that not only tabular data can be generated, but also data for NoSQL databases. • Reproducible: By sharing the schema definition, others can create the same data. • Scalable: Various options for scaling are available. This means that even large amounts of data can be used. This makes it possible to examine the scalability of data cleaning tools. Data quality is thus ensured even in applications with large amounts of data. • Error types: A variety of different error types can be generated. These are shown in Table 1 and described in greater detail in the next section. Due to the comprehensive error definition, the data can be tailored precisely to the use case. It allows for many different aspects of data quality to be taken into account. • Error rate: The occurrence rate is freely configurable for each error, the errors are distributed randomly. It is also planned to include other error mechanisms [LR19] such as Missing At Random (MAR) and Missing Not At Random (MNAR) in a future version. The freely adjustable error rate allows the impact of errors on subsequent analyses to be examined more closely. • Ground truth: Ground truth is provided. The generated errors are additionally logged in a file. This allows for a more detailed examination of data quality. It is possible to determine how close the cleaning is to the ground truth. It is also possible to analyze whether all errors could be corrected. This represents a major advantage over real data, where ground truth is usually unavailable or can only be created with great effort. Table 1: Error types supported by GouDa Level
An Attribute Value of a Single Tuple
The Values of a Single Attribute The Attribute Values of a Single Tuple The Attribute Values of Several Tuples
3.2
Error Type Missing value Syntax violation Interval violation Set violation Misspelled error Inadequate value to the attribute context Value items beyond the attribute context Meaningless Value Erroneous entry* Uniqueness value violation Synonyms existence Outlier* Missing Attribute* Semi-empty tuple Inconsistency among attribute values Irrelevant observation* Redundancy about an entity Inconsistency about an entity Bias* Noise*
Error Types
As described, errors can be added to the data in a controlled manner using error generators. Many different definitions of error types are presented in literature [RD00, KCH+ 03, MF03, ORHG05, LPK11]. The classification of GouDa (see Table 1) is based on the definition of Oliveira et al. [ORHG05]. This definition follows a bottom-up approach in which the errors are classified into six different levels. These levels can be divided into several groups: A distinction is made between Single Data Source and Multiple Data Sources (comparable to the definition of [RD00]). The group of Single Data Source can be further divided into Single Relation and Relationships among Multiple Relations. The group 4
Extending GouDa: Generation of Universal Datasets with (and without) Errors for Data Quality Benchmarking
Single Relation includes the four lowest levels An Attribute Value of a Single Tuple, The Values of a Single Attribute, The Attribute Values of a Single Tuple, and The Attribute Values of Several Tuples. The approach is well suited to the controlled generation of errors because of the bottom-up approach. Error generation was first started on the lowest level (An Attribute Value of a Single Tuple). Then other levels were added step by step. The definition by Oliveira et al. [ORHG05] is already very comprehensive and includes a large part of error types from other works. In addition, the classification has been extended to include further important error types, based on [RD00, KCH+ 03, MF03, LPK11]. This concerns e.g. outlier and bias. The corresponding types are marked with a * in Table 1. Some definitions from [ORHG05] were not taken into account. One example is Outdated Value. The goal of GouDa is to create a static data set. In this context, an outdated value would not be recognizable. For the same reason, the last level (Multiple Data Sources) of [ORHG05] is not considered. The focus is only on static data sets and not on errors caused by merging multiple data sources. This is intended for a future version of GouDa. To ensure that the error types reflect real-world conditions, we analyzed real-world data from a global pharmaceutical and diagnostics company. Table 2 shows the occurring error types and their frequency. The analysis shows that the errors we selected for GouDa are not only cited in various scientific papers [RD00, KCH+ 03, MF03, ORHG05, LPK11] but also occur in practice. Table 2: Occurrence and frequency of data errors in applications of the information system at a production site of a global pharmaceutical and diagnostics company. No frequency was specified for the error type synonyms existence, as there was no official entry indicating which term is the correct one.
3.3
System
Data Storage
Error Type
Frequency
System A
MS SQL Server
Missing value Redundancy about an entity
6.9% 5.7%
System B
Asset Framework DB
Missing value Erroneous entry
0.1% 11.5%
System C
MS SQL Server
Erroneous entry Inconsistency about an entity
0.1% 0.2%
Multiple
Multiple
Synonyms existence
Architecture and Usage
GouDa implements a monolithic, technically partitioned layered architecture. Its four main layers are the presentation layer, the application service layer, the domain layer, and the infrastructure layer. Additionally a layer for cross-cutting concerns provides utilities such as logging and performance monitoring. An overview of the high level architecture is shown in Figure 1. As can be seen, GouDa is provided with two Docker containers, one for the frontend and one for the backend. The frontend contains the presentation layer, where the GUI is located. The implementation is done with React3 . The frontend communicates with the backend via a REST API, located in the application service layer. The domain layer and infrastructure layer are also part of the backend. The domain layer contains the generators described above and the abstract data model, which is used for validation. The backend is realized with Spring Boot4 . Therefore the only dependencies for using GouDa are Docker and Docker Compose. To get GouDa up and running first the GouDa Git repository5 needs to be cloned. After that, within the main directory, the following command can be executed to start the application: docker compose up
This will start both the frontend and the backend. The GUI can then be accessed via http://localhost. 3
https://react.dev/ https://spring.io/projects/spring-boot 5 https://gitlab.com/cheese-board/gouda 4
5
Extending GouDa: Generation of Universal Datasets with (and without) Errors for Data Quality Benchmarking
Frontend
Presentation Layer Graphical User Interface (GUI)
REST API
Application Service Layer Domain Layer Generators
Backend
Plain Generators Dictionary Generators
GSD Abstract Data Model
Error Generators
Infrastructure Layer
Figure 1: GouDa High Level Architecture
4
Example of GouDa in use
In this section, we use an example to show how data can be generated with GouDa. We will show how the generators available in GouDa can be used to flexibly generate synthetic data. A complete list of all generators (including error generators) can be found here: https://gitlab.com/cheese-board/gouda. GouDa can be used to generate synthetic data in a variety of ways. In particular, realistic data can also be recreated. This approach has various advantages, for example, in terms of scaling and the controlled insertion of error types and error rates. In this chapter, we illustrate these possibilities using an example and discuss the specific possibilities and advantages of this approach. To highlight the advantages of synthetic data while remaining as realistic as possible, we have recreated a real-world data set about beers. This data set is used by Mahdavi et al. [MAF+ 19], among others, in the context of error detection research. They scraped the data from the web, cleaned it manually, and then inserted errors. Both the erroneous (dirty.csv) and the clean (clean.csv) versions of the data are publicly available 6 . The data set contains the following attributes: • id: A random ID (integer), identifying the record (integer) – for this purpose, we simply chose a sequential number. This is included by default in every data record generated with GouDa. • beer-name: The name of the beer (text) – we extracted all distinct beer names from the clean.csv file and added them as a custom list. Even though we have used real data as a reference here, no real data is required for the use of GouDa as described. The lists could thus also be generated manually, by an LLM, or by other means. As mentioned, GouDa already comes with various lists (e.g., for names or brands). • style: The style of the beer (text) – we extracted all styles from the clean.csv file and add a custom map with the beer-name as key and the style as value. This way, we can add the correct styles to the beer names. Here, again, the use of an LLM would be a viable alternative. 6
https://github.com/BigDaMa/raha/tree/master/datasets/beers
6
Extending GouDa: Generation of Universal Datasets with (and without) Errors for Data Quality Benchmarking
• ounces: Size of the beer (float) – for this purpose, we selected the distinct values of the attribute from clean.csv. Since there was only a set of seven distinct values, we chose a generator that selects randomly from this set. Here, it would also be possible to make the data generation even more realistic and generate values depending on the style for example. • abv: Alcoholic content by volume (float) – for this purpose, we chose the function that randomly generates floats. We extracted the min and max values of the attribute from clean.csv and passed them to the generator. Here again, it would also be possible to make the data generation even more realistic and generate values depending on the style for example. • ibu: International bitterness unit (float) – here we have chosen the same approach as for abv. • brewery: The name of the brewery (text) – comparable to beer-name, we extracted all distinct brewery names from clean.csv and added them as a custom list. • brewery-id: The ID of the brewery (integer) – comparable to style, we created a custom map with brewery as key and brewery-id as value. Alternatively, a simpler approach would also be conceivable, whereby each brewery is simply given a random unique id. • city: The city, where the brewery is located (text) – in order to obtain the correct city names, we created a custom map with the brewery as key and the city as value. • state: The corresponding state (text) – again, we used a custom map with the city as key and the state as value, to obtain the correct states to the city. The paper by Mahdavi et al. [MAF+ 19] states that the erroneous data set contains missing values, formatting issues, and violated attribute dependency. Applied to the error classification of GouDa, we have therefore included the following errors: • Missing values in 5% of beer-name • Missing values in 10% of ibu • Wrong units in 15% of ounces – the correct version is the value itself, e.g. 12.0 and for the errors we added the unit: 12.0 oz • Wrong units in 15% of abv – the correct version is the value itself, e.g. 0.005 and for the errors we added the unit: 0.005% • Derived value error in 5% of style: The style is dependent of the beer-name, for 5% we added the wrong style • Derived value error in 5% of state: The state is dependent of the city, for 5% we added the wrong state The GouDa Schema Definition (GSD) looks as follows: { "index": "{{Index(Index_1(0))}}", "beer-name": "{{error(\"MISSINGVALUE\", 5,put(\"beer-name\",customSet(\"beer-names.txt\")))}}", "style": "{{error(\"DERIVED_VALUE_ERROR\", 5, \"beer-styles.txt\",\"beer-name\")}}", "ounces": "{{error(\"WRONG_UNIT\", 15, random(12.0, 8.4, 16.0, 24.0, 19.2, 32.0, 16.9), \" oz\") }}", "abv": "{{error(\"WRONG_UNIT\", 15, double(0.001,0.1,\"%.3f\"), \"%\")}}", "ibu": "{{error(\"MISSINGVALUE\", 10, double(4.0,138.0,\"%.0f\"))}}", "brewery": "{{put(\"brewery\", customSet(\"breweries.txt\"))}}", "brewery-id": "{{customDerivedValue(\"brewery-map.txt\",get(\"brewery\"))}}", "city": "{{put(\"city\", customDerivedValue(\"brewery-city.txt\",get(\"brewery\")))}}", "state": "{{error(\"DERIVED_VALUE_ERROR\", 5, \"city-state.txt\",\"city\")}}", "Relationship": "{{Relationship(None,Relationship_1,Index_1,100)}}" }
By using the GUI, this can be generated without requiring a deeper understanding of the syntax of the GSD. In the following, we show an exemplary excerpt of the data 7
Extending GouDa: Generation of Universal Datasets with (and without) Errors for Data Quality Benchmarking
// ground truth { "index": "33", "beer-name": "Bomber Mountain Amber Ale (2013)", "style": "American Amber / Red Ale", "ounces": 16.9, "abv": 0.038, "ibu": 133, "brewery": "Bold City Brewery", "brewery-id": 378, "city": "Jacksonville", "state": "FL" }
// erroneous version { "index": "33", "beer-name": "", "style": "American Amber / Red Ale", "ounces": "16.9 oz", "abv": "0.038%", "ibu": 133, "brewery": "Bold City Brewery", "brewery-id": 378, "city": "Jacksonville", "state": "PA" }
The incorrect version is shown on the left. There are missing values in beer-name, formatting issues (wrong unit) in ounces and abv, and a violated attribute dependency between city and state. The right side shows the ground truth with the correct values. Discussion As can be seen, with GouDa we were able to recreate the data set very realistically. Even though the data was generated as JSON, a flat structure was created so that the data can be read in with pd.read_json() just as it would be with the pandas function pd.read_csv(). This emphasizes the flexibility of GouDa. Analysis of the clean.csv data set revealed the advantages of synthetically generated data. The data set was originally cleaned manually, but the following errors were still identified in the data: • There is an entry for the city Marquette with the state MA. This is incorrect; the correct state is MI. • The Brewery with the name Against the Grain Brewery appears in different spellings, twice as Against The Grain Brewery (with capital T) and 13 times as Against the Grain Brewery (with lowercase t). All entries refer to the city Louisville, but the two breweries have different values for brewery-id. The correct value is Against the Grain Brewery (with lowercase t). This shows that manual cleaning of data records is prone to errors. With GouDa, realistic data can be generated in a controlled manner so that only the intended errors are present in the data. The generation of synthetic data also offers further advantages: Depending on requirements, the existing error rates can easily be adjusted and additional errors can be added. The size of the data can also be adjusted as desired, so that the data can be easily used for scalability tests. If additional data types (e.g., date values) are required, these can also be added as additional attributes without much effort. It is also possible to split the data set into several data sets, e.g. by storing the breweries as a separate entity type. The appropriate relationship type can then be selected from the available options (e.g., N:M). In addition to recreating real data, purely synthetic data can also be created using GouDas numerous generators. Real data as a basis is not necessary. In summary, this example shows how GouDa can be used to leverage the advantages of synthetic data generation while still ensuring that the data remains realistic.
5
Conclusion and Future Work
In this paper, we have presented our data generator GouDa. GouDa is flexible in its application: the use of JSON enables support for many different data formats. A wide range of generator functions allows many different types of data to be created. In addition, you can add your own lists of possible attribute values and key-value pairs. This allows data to be generated in a realistic manner. Furthermore, it is possible to add controlled errors to the data while simultaneously generating an error-free version of the data. Multiple entity types can be generated, which can be linked to each other using different relationship types. All these features make GouDa a powerful data generator capable of generating FAIR data. This is particularly important for data quality research [JJCB25]. Take, for example, the generated synthetic beers dataset: The data is F(indable) and A(ccessible)7 . By using GSDs, which are JSON files, the data set is also I(nteroperable). The GSD is R(eusable) and can thus also be used by others to generate the data. Using an example, we have highlighted the advantages of generating synthetic data and demonstrated how GouDa can be used flexibly. In this way, we aim to contribute to a common benchmark of standardized data sets for reproducible data quality research. 7
https://gitlab.com/cheese-board/gouda
8
Extending GouDa: Generation of Universal Datasets with (and without) Errors for Data Quality Benchmarking
We are continuously developing GouDa so that other error mechanisms (such as MAR) will soon be possible. We also plan to add more generators to enable the creation of even more diverse data. As described, support for additional databases besides MongoDB is also expected to be added in the near future. Furthermore, we plan to add data generation for multiple data sources.
Acknowledgment GouDa would not be what it is today if we hadn’t worked with such great students: Thanks to Gerrit Boerner for most of the implementation work related to error generation. Thanks to the group of the Fachpraktikum from the winter semester 23/24, who created the initial GUI and the abstract data model, among other things. Many thanks to Martin Schmid, who merged the different versions, added tests, and created a comprehensive concept on the topic of software development in research contexts.
References [Abe25] Ziawasch Abedjan. Navigating disruption: The impact of AI technologies on data integration research. Keynote at the 2nd International Workshop on Data-Centric AI (DATAI), co-located with VLDB 2025, 2025. + [AGM 15] Patricia C. Arocena, Boris Glavic, Giansalvatore Mecca, Renée J. Miller, Paolo Papotti, and Donatello Santoro. Messing up with BART: error generation for evaluating data-cleaning algorithms. Proc. VLDB Endow., 9(2):36–47, 2015. [BKY19] Matthias Boehm, Arun Kumar, and Jun Yang. Data Management in Machine Learning Systems. Synthesis Lectures on Data Management. Morgan & Claypool Publishers, 2019. [CAS+ 18] Jeroen Castelein, Maurício Finavaro Aniche, Mozhan Soltani, Annibale Panichella, and Arie van Deursen. Search-based test data generation for SQL queries. In ICSE, pages 1220–1230, New York, NY, 2018. ACM. [CMK+ 21] André Conrad, Mark Lukas Möller, Tobias Kreiter, Jan-Christopher Mair, Meike Klettke, and Uta Störl. Evobench: Benchmarking schema evolution in nosql. In TPCTC, volume 13169 of Lecture Notes in Computer Science, pages 33–49, Heidelberg, 2021. Springer. [CRM20] Alberto Hernández Chillón, Diego Sevilla Ruiz, and Jesús García Molina. Deimos: A model-based nosql data generation language. In ER (Workshops), volume 12584 of Lecture Notes in Computer Science, pages 151–161, Heidelberg, 2020. Springer. [EN25] Lisa Ehrlinger and Felix Naumann. Data Quality for Enterprise AI, pages 91–128. Springer Nature Switzerland, Cham, 2025. [EVT22] Markus Endres, Asha Mannarapotta Venugopal, and Tung Son Tran. Synthetic data generation: A comparative study. In IDEAS, pages 94–102, New York, NY, 2022. ACM. [GA14] Stefan J. Galler and Bernhard K. Aichernig. Survey on test data generation tools - an evaluation of whiteand gray-box testing tools for c#, c++, eiffel, and java. Int. J. Softw. Tools Technol. Transf., 16(6):727–751, 2014. [jF26] joke2k and Faker contributors. Faker: Python package that generates fake data for you, 2026. Python package, accessed 22 July 2026. [JJCB25] Philipp Jung, Sebastian Jäger, Nicholas Chandler, and Felix Biessmann. Towards realistic error models for tabular data. ACM Journal of Data and Information Quality, 17(4):1–27, 2025. [JS20] Nishtha Jatana and Bharti Suri. An improved crow search algorithm for test data generation using search-based mutation testing. Neural Process. Lett., 52(1):767–784, 2020. [KCH+ 03] Won Y. Kim, Byoung-Ju Choi, Eui Kyeong Hong, Soo-Kyung Kim, and Doheon Lee. A taxonomy of dirty data. Data Min. Knowl. Discov., 7(1):81–99, 2003. [LPK11] Lin Li, Taoxin Peng, and Jessie Kennedy. A rule based taxonomy of dirty data. GSTF Journal on Computing (JoC), 1(2), 2011. [LR19] Roderick JA Little and Donald B Rubin. Statistical analysis with missing data, volume 793. John Wiley & Sons, 2019. [MA20] Mohammad Mahdavi and Ziawasch Abedjan. Baran: Effective error correction via a unified context representation and transfer learning. Proc. VLDB Endow., 13(11):1948–1961, 2020. 9
Extending GouDa: Generation of Universal Datasets with (and without) Errors for Data Quality Benchmarking
[MAF+ 19] Mohammad Mahdavi, Ziawasch Abedjan, Raul Castro Fernandez, Samuel Madden, Mourad Ouzzani, Michael Stonebraker, and Nan Tang. Raha: A configuration-free error detection system. In SIGMOD Conference, pages 865–882, New York, NY, 2019. ACM. [MAK+ 23] Hajra Murtaza, Musharif Ahmed, Naurin Farooq Khan, Ghulam Murtaza, Saad Zafar, and Ambreen Bano. Synthetic data generation: State of the art in health care domain. Comput. Sci. Rev., 48:100546, 2023. [MF03] Heiko Müller and Johann Christoph Freytag. Problems, methods, and challenges in comprehensive data cleansing. Technical report hub-ib-164, Humboldt University, 2003. [ORHG05] Paulo Oliveira, Fátima Rodrigues, Pedro Henriques, and Helena Galhardas. A taxonomy of data quality problems. In 2nd Int. Workshop on Data and Information Quality, pages 219–233, Heidelberg, 2005. [PSH17] Haoyue Ping, Julia Stoyanovich, and Bill Howe. Datasynthesizer: Privacy-preserving synthetic datasets. In SSDBM, pages 42:1–42:5. ACM, 2017. [RBCS22] Valerie Restat, Gerrit Boerner, André Conrad, and Uta Störl. Gouda - generation of universal data sets: Improving analysis and evaluation of data preparation pipelines. In DEEM@SIGMOD, pages 2:1–2:6, New York, NY, 2022. ACM. [RD00] Erhard Rahm and Hong Hai Do. Data cleaning: Problems and current approaches. IEEE Data Eng. Bull., 23(4):3–13, 2000. [Res23] Gartner Research. How poor data quality costs organizations $12.9 million annually. Technical report, Gartner, 2023.
10