CodeCritics Applied to Database Schema: Challenges and First Results
- 1. CodeCritics Applied to Database Schema: Challenges and First Results Julien Delplanque1,2 Anne Etien2 Olivier Auverlot2 Tom Mens1 Nicolas Anquetil2 St´ephane Ducasse2 1Universit´e de Mons, Belgique julien.delplanque@student.umons.ac.be tom.mens@umons.ac.be 2Universit´e de Lille, CNRS, Inria, Centrale Lille, UMR 9189 - CRIStAL, F-59000 Lille, France {nom.prenom}@univ-lille1.fr 1 / 35
- 2. Use Case Scenario I Smells detection DBAs need tools to highlight smells, anti-patterns and violations of business rules. 2 / 35
- 3. Use Case Scenario I Smells detection DBAs need tools to highlight smells, anti-patterns and violations of business rules. Rule = a property that the database should have 3 / 35
- 4. Use Case Scenario I Smells detection DBAs need tools to highlight smells, anti-patterns and violations of business rules. Rule = a property that the database should have • Generic rules e.g., foreign keys reference primary keys 4 / 35
- 5. Use Case Scenario I Smells detection DBAs need tools to highlight smells, anti-patterns and violations of business rules. Rule = a property that the database should have • Generic rules e.g., foreign keys reference primary keys • Company or database-specific rules e.g., ensure the respect of naming convention 5 / 35
- 6. Use Case Scenario II DBMS version migration DBMS evolves to introduce new features or to fix bugs. 6 / 35
- 7. Use Case Scenario II DBMS version migration DBMS evolves to introduce new features or to fix bugs. • Upgrade migration patches are rarely provided 7 / 35
- 8. Use Case Scenario II DBMS version migration DBMS evolves to introduce new features or to fix bugs. • Upgrade migration patches are rarely provided • Sometimes a textual change log is provided 8 / 35
- 9. Use Case Scenario II DBMS version migration DBMS evolves to introduce new features or to fix bugs. • Upgrade migration patches are rarely provided • Sometimes a textual change log is provided • DBAs need to identify the migration impact 9 / 35
- 10. Use Case Scenario III Maintaining consistency A DB schema may be used as a basis for multiple projects. 10 / 35
- 11. Use Case Scenario III Maintaining consistency A DB schema may be used as a basis for multiple projects. • Need to integrate the changes to profit from the original schema updates 11 / 35
- 12. Use Case Scenario III Maintaining consistency A DB schema may be used as a basis for multiple projects. • Need to integrate the changes to profit from the original schema updates • The consistency of the DB should be kept after an update 12 / 35
- 13. Additionally... • All kind of entities (tables, columns, views, functions, . . . ) and the relationships between them are potentially subject to quality defects 13 / 35
- 14. Additionally... • All kind of entities (tables, columns, views, functions, . . . ) and the relationships between them are potentially subject to quality defects • Checking for domain-specific or system-specific rules provides better defect prevention 14 / 35
- 15. Additionally... • All kind of entities (tables, columns, views, functions, . . . ) and the relationships between them are potentially subject to quality defects • Checking for domain-specific or system-specific rules provides better defect prevention • Automatic detection of quality problems is important but resolving them is the ultimate goal 15 / 35
- 16. Additionally... • All kind of entities (tables, columns, views, functions, . . . ) and the relationships between them are potentially subject to quality defects • Checking for domain-specific or system-specific rules provides better defect prevention • Automatic detection of quality problems is important but resolving them is the ultimate goal • Resolving an issue on an entity may imply changes on other entities 16 / 35
- 17. Table of contents 1 Introduction 2 DBCritics 3 Case Studies 17 / 35
- 18. Overview ⇒ Apply traditional Software Quality Analysis methods to database schemas 18 / 35
- 19. Examples of rules 1 Detect use of * in SELECT request 19 / 35
- 20. Examples of rules 1 Detect use of * in SELECT request 2 View using another view 20 / 35
- 21. Examples of rules 1 Detect use of * in SELECT request 2 View using another view 21 / 35
- 22. Examples of rules 1 Detect use of * in SELECT request 2 View using another view 22 / 35
- 23. Examples of rules 1 Detect use of * in SELECT request 2 View using another view 23 / 35
- 24. Examples of rules 1 Detect use of * in SELECT request 2 View using another view 24 / 35
- 25. Table of contents 1 Introduction 2 DBCritics 3 Case Studies 25 / 35
- 26. Evaluation Discovering rule violations on two real databases • WikiMedia: 25 versions analysed • AppSI: 12 versions analysed WikiMedia AppSI Tables 30/51 71/91 Columns 196/353 583/974 View 0/1 30/52 Functions 3/5 46/67 Triggers 2/3 12/16 LOC 1,435/2,453 4,910/7,006 Min/Max number of entities per type for each database. 26 / 35
- 27. Violation count per version Rule violations can be found in open source as well as in proprietary DB schemas. 27 / 35
- 28. Violating entities proportion Dashed: violating entities, Solid: entities count. The number of violating entities evolves with the total number of entities. 28 / 35
- 29. “Time-to-fix” of a rule violation Corrected violations: • WikiMedia (WM): 21/87 • AppSI: 3/85 ⇒ On both DBs some violations are fixed but not all of them. 29 / 35
- 30. “Time-to-fix” of a rule violation Corrected violations: • WikiMedia (WM): 21/87 • AppSI: 3/85 ⇒ On both DBs some violations are fixed but not all of them. Time in days needed to correct violations: Min 1st quantile Median 3rd quantile Max WM 95 1227 1833 2403 3644 AppSI 3 / 125 / 278 30 / 35
- 31. False positives Three categories of violations can be distinguished: 1 Real design issues 2 Issues that the DBA accept to live with 3 Issues due to limitations of DBCritics 31 / 35
- 32. False positives Three categories of violations can be distinguished: 1 Real design issues 2 Issues that the DBA accept to live with 3 Issues due to limitations of DBCritics Classifying violations in these categories can not be automated. 32 / 35
- 33. False positives Three categories of violations can be distinguished: 1 Real design issues 2 Issues that the DBA accept to live with 3 Issues due to limitations of DBCritics Classifying violations in these categories can not be automated. On AppSI v10, the DBA analysed the 81 rule violations: Category Count 1 51 2 8 3 22 ⇒ Can not be generalised, just gives an idea. 33 / 35
- 34. Conclusion • Relational databases are at the core of many information systems • As any artefact, they are subject to errors and quality defects • Empirical study on two real DB supporting the relevance of the approach • External validation based on the feedback of AppSI’s DBA supporting the relevance of the tool’s results 34 / 35
- 35. Questions • Do open-source and proprietary DB schemas behave differently in terms of rule violations? • How to practically integrate such an approach in the DB life-cycle? • How to convince DBAs of the relevance of the approach since they have lived without such tools for years? 35 / 35