Relational databases (DB) play a critical role in many information systems. For different reasons, their schemas gather not only tables and columns but also views, triggers or stored functions (i.e., fragments of code describing treatments). As for any other code-related artefact, software quality in a DB schema helps avoiding future bugs. However, few tools exist to analyse DB quality and prevent the introduction of technical debt. Moreover, these tools suffer from limitations like the difficulty to deal with some entities (e.g., functions) or dependencies between entities. This paper presents research issues related to assessing the software quality of a DB schema by adapting existing source code analysis research to database schemas. We present preliminary results that have been validated through the implementation of DBCritics, a prototype tool to perform static analysis on the SQL source code of a database schema. DBCritics addresses the limitations of existing DB quality tools based on an internal representation considering all entities of the database and their relationships. These slides were presented at SANER 2017, Austria.

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