Click here to learn more about author Michael Blaha.

This article is the second in a series of two blogs that present our grading scale for database quality. Read Part 1 here: Grading Database Quality, Part 1: Database Designs. We assign separate grades for the quality of a database design (previous blog) and the underlying model (this blog). The design grade measures the quality of the database syntax. The model grade measures the quality of the semantic concepts underlying the database. Applications can have different design and model grades.

Database Grading

Here is our grading scale for database models. We use grades of “A”, “B”, “C”, “D”, and “F”. “A” is the best grade and “F” is the worst grade with “B”, “C”, and “D” denoting intermediate quality.

A database model with a grade of ‘A’ is expertly crafted. Given the demonstrated proficiency, it’s likely that the corresponding software is also of high quality.

A database model with a grade of ‘B’ is still quite good, but not perfect. Some might regard the distinction between ‘A’ and ‘B’ as quibbling. As an example, the anonymous fields address1, address2, address3, address4, and address5 can store address data. A better representation would be street_address, city_name, state_province_name, postal_code, and country_name.

A database design with a grade of ‘C’ is mediocre. It serves business needs, but should be better. As an example, databases for some object-oriented applications generalize most entity types. A base table propagates its primary key to the other tables. We call this excessive generalization. Such a generalization seldom has a basis in reality – thus it is not a conceptual insight. Rather it mirrors the programming approach. It would be better to simplify the database and avoid such primary key progagation. The database must correspond to programming data structures, but need not mirror them.

A database design with a grade of ‘D’ is defective. It is poor quality work. Arbitrary decisions are always undesirable in software. For example, it’s not a good idea to have names with a small size. Similarly, it’s not helpful to have a maximum limit on the number of items in an order. As an example of poor abstraction, we encountered a model that confuses Contracts with Contract Versions.

A database design with a grade of ‘F’ is an embarrassment. Such a design is a hack and reflects a lack of understanding of databases.

In Conclusion

In practice, we find that most modern database designs are of reasonable quality (grade of A, B, or C). We believe this is because of the many excellent database design tools available on the market. Many developers are using them.

In contrast, the quality of database models vary more. Tools help with the mechanics of modeling but do not address the content. Rather developers must conceive and prepare database models on their own. The quality of a database model depends on the skill and experience of the developer.