Understanding database schema evolution: A case study

Cleve, Anthony; Gobert, Maxime; Meurice, Loup; Maes, Jerome; Weber, Jens H.

doi:10.1016/j.scico.2013.11.025

Cited by 40 publications

(17 citation statements)

References 12 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…Cleve et al [9] researched a schema evolution of a database in which the number of tables grew roughly from 100 to 450. A database of hundreds of tables creates a need for namespaces of different levels, and the queries to such databases need correlation names of corresponding levels.…”

Section: Syn-1 Ambiguous Databasementioning

confidence: 99%

Errors and Complications in SQL Query Formulation

Taipalus

Siponen

Vartiainen

2018

ACM Trans. Comput. Educ.

View full text Add to dashboard Cite

SQL is taught in almost all university level database courses, yet SQL has received relatively little attention in educational research. In this study, we present a database management system independent categorization of SQL query errors that students make in an introductory database course. We base the categorization on previous literature, present a class of logical errors that has not been studied in detail, and review and complement these findings by analyzing over 33,000 SQL queries submitted by students. Our analysis verifies error findings presented in previous literature and reveals new types of errors, namely logical errors recurring in similar manners among different students. We present a listing of fundamental SQL query concepts we have identified and based our exercises on, a categorization of different errors and complications, and an operational model for designing SQL exercises.

show abstract

Section: Syn-1 Ambiguous Databasementioning

confidence: 99%

Errors and Complications in SQL Query Formulation

Taipalus

Siponen

Vartiainen

2018

ACM Trans. Comput. Educ.

View full text Add to dashboard Cite

show abstract

“…Schema evolution is basically altering the schema of the database to adapt it to a certain required change [4]. Attempts have been made to analyze the schema evolution from earlier versions [8], and tools have been developed to automate the evolution process [27]. However, schema evolution literature has focused on limited database refactoring tactics, such as adding or renaming a column, changing the data type, etc.…”

Section: Database Refactoringmentioning

confidence: 99%

Prioritizing technical debt in database normalization using portfolio theory and data quality metrics

Albarak

Bahsoon

2018

Proceedings of the 2018 International Conference on Technical Debt

View full text Add to dashboard Cite

Database normalization is the one of main principles for designing relational databases. The benefits of normalization can be observed through improving data quality and performance, among the other qualities. We explore a new context of technical debt manifestation, which is linked to ill-normalized databases. This debt can have long-term impact causing systematic degradation of database qualities. Such degradation can be liken to accumulated interest on a debt. We claim that debts are likely to materialize for tables below the fourth normal form. Practically, achieving fourth normal form for all the tables in the database is a costly and idealistic exercise. Therefore, we propose a pragmatic approach to prioritize tables that should be normalized to the fourth normal form based on the metaphoric debt and interest of the ill-normalized tables, observed on data quality and performance. For data quality, tables are prioritized using the risk of data inconsistency metric. Unlike data quality, a suitable metric to estimate the impact of weakly or un-normalized tables on performance is not available. We estimate performance degradation and its costs using Input\Output (I\O) cost of the operations performed on the tables and we propose a model to estimate this cost for each table. We make use of Modern Portfolio Theory to prioritize tables that should be normalized based on the estimated I\O cost and the likely risk of cost accumulation in the future. To evaluate our methods, we use a case study from Microsoft, AdventureWorks. The results show that our methods can be effective in reducing normalization debt and improving the quality of the database.

show abstract

“…We ground this choice on previous case studies that argue that AD principles are hard to implement in software systems, because of the interdependence of data models and the behavior of the system [23]. The interdependency of data models and application code has been extensively studied in IS research [24][25][26][27].…”

Section: B Conceptual Independencementioning

confidence: 99%

Unintended effects of dependencies in source code on the flexibility of IT in organizations

Tarenskeen

Wetering²,

Bakker

2018

Annals of Computer Science and Information Systems

View full text Add to dashboard Cite

This study links business requirements and adaptability of existing software systems. Organizations expect flexibility of IT with regard to business requirements. We hypothesize that the flexibility of business requirements is difficult in IT systems, because of software dependencies in the way domain knowledge is implemented. In this paper, we, therefore, explore how Business requirements have been implemented in the source code of three open source healthcare systems. Outcomes suggest that a tight interdependency of business terminology and functionality in source code hides business requirements from view and thereby hinders IT flexibility on higher levels.

show abstract

Understanding database schema evolution: A case study

Cited by 40 publications

References 12 publications

Errors and Complications in SQL Query Formulation

Errors and Complications in SQL Query Formulation

Prioritizing technical debt in database normalization using portfolio theory and data quality metrics

Unintended effects of dependencies in source code on the flexibility of IT in organizations

Contact Info

Product

Resources

About