picture by Greg via Flickr
This article is the second in a series of two blogs that present our grading scale for database quality. 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.
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.
|Grade||Explanation||Model Flaw Examples|
|A||The database has no major flaws. The style is reasonable and uniform.|
|B||The database has flaws that are not apparent in the software’s operation. The flaws can be easily repaired.||• Entity types have anonymous fields that application code must interpret.
• The model has extraneous content.
|C||The database has major flaws that are difficult to fix and cause noticeable problems (bugs, slow performance, difficult maintenance) in the application.||• The model has needless complexity.
• There is excessive generalization.
• There are major modeling errors.
|D||The database has severe flaws that compromise the application.||• There are many arbitrary restrictions.
• The model is poorly abstracted.
|F||The database is appalling. The application runs only because of brute-force programming effort.||• There are gross conceptual errors.|
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 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.