77 lines
5.4 KiB
Markdown
77 lines
5.4 KiB
Markdown
tags:: [[#zotero]]
|
||
date:: 2024
|
||
title:: @Estimation, Impact and Visualization of Schema Evolution in Graph Databases
|
||
item-type:: [[journalArticle]]
|
||
original-title:: "Estimation, Impact and Visualization of Schema Evolution in Graph Databases"
|
||
language:: en
|
||
authors:: [[Dominique Hausler]]
|
||
library-catalog:: Zotero
|
||
links:: [Local library](zotero://select/library/items/4PIZV7JR), [Web library](https://www.zotero.org/users/1039502/items/4PIZV7JR)
|
||
|
||
- [[Abstract]]
|
||
- Graph databases offer a flexible storage of interconnected data. Due to NoSQL databases being schemaless, heterogeneous data can occur when performing data changes. Evolution is conducted through so called evolution operations like add, rename, delete, merge, copy, move or split. As a user can not foresee the results of the evolution operation neither the amount of data changes nor the possible schema violations or a relaxed schema, a system to show the impact of evolution is essential. To ensure schema conformity, we present an approach to close the gap of a schema management tool for graph databases in order to estimate and illustrate the impact of evolution on the schema level. To illustrate, explore, evolve and change the schema all required information is handled through a schema management layer. Besides extracting the schema, so called structure profiles are designed for an initial data exploration. The preview of the schema and structure profiles shows the impact of evolution on the data by comparing versions. Moreover, the system uses an intuitive syntax to also enable the usage of graph databases for non-experts.
|
||
- ### Attachments
|
||
- [File PDF](zotero://select/library/items/9ZGTXUZS) {{zotero-imported-file 9ZGTXUZS, "Hausler - 2024 - Estimation, Impact and Visualization of Schema Evolution in Graph Databases.pdf"}}
|
||
- ### Notes
|
||
- # Annotazioni
|
||
(22/7/2024, 16:05:35)
|
||
|
||
- “Schema Evolution in Graph Databases” (Hausler, 2024, p. 1) #5fb236
|
||
|
||
- “Due to NoSQL databases being schemaless, heterogeneous data can occur when performing data changes.” (Hausler, 2024, p. 1) #5fb236
|
||
|
||
- “As a user can not foresee the results of the evolution operation neither the amount of data changes nor the possible schema violations or a relaxed schema, a system to show the impact of evolution is essential.” (Hausler, 2024, p. 1) #a28ae5
|
||
|
||
- “estimate and illustrate the impact of evolution on the schema level” (Hausler, 2024, p. 1) #5fb236
|
||
|
||
- “structure profiles are designed for an initial data exploration” (Hausler, 2024, p. 1) #5fb236
|
||
|
||
- “Due to graph database offering schemalessness, heterogeneity can occur through optional elements or structural error.” (Hausler, 2024, p. 1) #5fb236
|
||
|
||
- “our goal is to involve users by informing them about such occurrences and giving the option to make changes if needed.” (Hausler, 2024, p. 1) #5fb236
|
||
|
||
- “Schema Management Layer (SML)” (Hausler, 2024, p. 1) #5fb236
|
||
|
||
- “schema and statistical information can be extracted, compared and constraints detected.” (Hausler, 2024, p. 1) #ffd400
|
||
*This seems not new. What's the novelty with respect to existing work?
|
||
|
||
I'm missing relevant work from Atzeni et al. like:
|
||
|
||
Paolo Atzeni, Francesca Bugiotti, Luca Cabibbo, Riccardo Torlone:
|
||
Data modeling in the NoSQL world. Comput. Stand. Interfaces 67 (2020)
|
||
|
||
Paolo Atzeni, Francesca Bugiotti, Luca Rossi:
|
||
Uniform access to NoSQL systems. Inf. Syst. 43: 117-133 (2014)
|
||
|
||
Francesca Bugiotti, Luca Cabibbo, Paolo Atzeni, Riccardo Torlone:
|
||
Database Design for NoSQL Systems. ER 2014: 223-231
|
||
|
||
Concerning the evolution management, the author should also consider:
|
||
|
||
Maxime Gobert, Loup Meurice, Anthony Cleve:
|
||
Modeling, manipulating and evolving hybrid polystores with HyDRa. Sci. Comput. Program. 230: 102972 (2023)
|
||
|
||
Maxime Gobert, Csaba Nagy, Henrique Rocha, Serge Demeyer, Anthony Cleve:
|
||
Best practices of testing database manipulation code. Inf. Syst. 111: 102105 (2023)
|
||
|
||
Anthony Cleve, Maxime Gobert, Loup Meurice, Jerome Maes, Jens H. Weber:
|
||
Understanding database schema evolution: A case study. Sci. Comput. Program. 97: 113-121 (2015)
|
||
|
||
Compared to such related work, I see potential novelty mainly concerning RQ3 and RQ4.*
|
||
|
||
- “the schema extraction paired with the information extraction for structure profiles is new” (Hausler, 2024, p. 1) #ffd400
|
||
*Why? What's the limitation of existing work?*
|
||
|
||
- “RQ3: How to estimate the effort and illustrate the impact of evolution operations as well as the affected elements? • RQ4: What kind of optimizations are needed?” (Hausler, 2024, p. 2) #ffd400
|
||
*Maybe this part is new. Concerning RQ1 and RQ2, they are related to existing work that is not mentioned.*
|
||
|
||
- “his limitation is due to schema evolution affecting only the property names np .” (Hausler, 2024, p. 3) #5fb236
|
||
|
||
- “estimate and display the affected elements through the Preview Module.” (Hausler, 2024, p. 4) #ffd400
|
||
*What do you mean with estimate? What kinds of estimation are you supporting?*
|
||
|
||
- “Schema evolution is conducted through the evolution operations add, rename, delete, copy, move, split and merge” (Hausler, 2024, p. 5) #5fb236
|
||
|
||
- “estimation of the impact of evolution on the database” (Hausler, 2024, p. 5) #5fb236
|
||
|
||
- “easy-to-understand language called GEO.” (Hausler, 2024, p. 5) #a28ae5 |