There is an old joke that a tourist in New York City is lost while sightseeing and notices a musician leaving a taxi; he walks up to the musician and asks, “How do you get to Carnegie Hall?” The musician responds, “Practice, practice, practice.” Obviously, such jokes are doomed to obscurity as people now will simply use the navigation app on their phone. However, the advice itself, in its own way, will always be relevant—practice, practice, practice.
Designing databases is not a clerical function. One does not apply simple automated transformations to get from A to B. Yes, there are an abundance of steps and pieces. Some of those steps may be largely automatic, even if the tools do not automate them. A novice data modeler may be overwhelmed by the variety of detail; things can appear quite mind-numbing. But those who simply ignore the complexities and assume everything is a virtual automatic cut, paste, and repeat will be doomed to create models that, at best, are sloppy, or at worst, wrong. Speed kills—rushing through the design steps is a great way to make more than the average numbers of mistakes. The designer is the creator; if she/he leaves a simple typographical error in a column name or a column definition, it may remain there forever. And across eternity, users viewing those typos will remind themselves just how stupid the data modelers who put things together were—they cannot even spell correctly. Larger errors will engender greater responses and animosity. Once the database tables are rolled out, developers write the code that populates and updates those tables. Report writers start writing scripts to extract data from those tables. If things need to be changed across the names of columns within those tables, “just” changing a column on a single table may require changing the code within many modules and across many reports. The correction effort itself may constitute a small project of its own.
Attention to detail is paramount in database design. A certain level of functional OCD (Obsessive-Compulsive Disorder) is almost a job requirement for certain IT jobs, including data modelers and DBAs. Before data modeling tools came into existence and automated many aspects of the database design efforts, this work was all done by hand. And for IT shops that refuse to invest in such tools, the work still is largely manual. This makes the challenge of creating and maintaining data models quite an endeavor. I know of one DBA who had a rule that major changes were not to go into production until she reviewed her work three separate times—and if possible, across 3 different days. Yes, this meant a lag of 3 days for migrating database changes into production. But, the number of defects found after things were in production was near zero and much, much lower than the error rates among her peers. Ultimately, the 3 days she spent making sure her change scripts were as correct as possible were much less costly than the weeks of fixing and reworking from her peers.
Everyone needs to find their own way to transcend such issues as typos or other errors. Multiple-pass error-checking or other rituals may help. The actual implementation tactics one uses are unimportant; the only critical thing is the result. Therefore, each designer needs to find an approach that works for them, one that addresses the kinds of errors they are prone to making and how to overcome them.
To work through establishing the rituals and the mindsets necessary to consistently achieve competence in delivering clean data models requires commitment of the data modeler—and practice, practice, practice.