Database modeling has some science, some art, a lot of techniques, and quite a bit of general wisdom. All good database modelers study a lot, practice a lot, cultivate creativity, and develop interpersonal skills. The road to becoming a database designer may seem arduous. But if you enjoy working with data, giving structure where there seemingly is none, and helping people find hidden truths in tides of information, you will definitely find the journey enjoyable.
Thinking of a database design for audit logging? Remember what happened to Hansel and Gretel: they thought leaving a simple trail of breadcrumbs was a good way to trace their steps. When we design a data model, we are trained to apply the philosophy that now is all that exists. For example, if we design a schema to store prices for a product catalog, we may think that the database only needs to tell us the price of each product at the present moment.
Think of them as your sidekicks to deal with the challenges you encounter every day in working with databases. Good database tools come to the rescue in all stages of the database lifecycle: from the conceptual design, through logical/physical design, all the way to maintenance, refactoring, and optimization. Every database professional, be it an architect, engineer, designer, programmer, tester, or administrator, has a preferred set of tools. Some tools are specific to the database system (RDBMS), such as MySQL, Oracle, SQL Server, or PostgreSQL, while others work with virtually any database engine.
Sharing is a good habit. The guys at Vertabelo know this, so they have made a big effort to make sharing database models with your clients very easy. True story: there was a time in my life when, in order to show a data model to a client, I had to print it on several sheets of paper. Then – using scissors, tape, and a fair amount of manual dexterity – I had to compose it into a sort of poster that would allow me to display all of its details.
Feeling overwhelmed by the amount of time it will take you to learn to be a database designer? Read about the essential skills and talents you’ll need – it’s not so terrible! When you walk down the aisles of the supermarket, shopping cart in one hand and grocery list in the other, what are you thinking? If you're like me, you're imagining how to improve the organization of the shelves so that your weekly shopping is less time-consuming.
Find out who’s who in the database department and decide which role you most identify with. In small companies, there is usually only one database job. The person in that position may be an architect one day, a designer the next day, a programmer another day, an administrator the day after that, and sometimes even an analyst or even a data scientist. If you’re planning to work in a small company, you should get used to the idea that you’ll be known as “the database guy/gal” and you’ll have to do a little bit of everything.
What – I can’t just let it be called Table_1? After decades of working with databases, I’ve come across all kinds of naming conventions in database modeling, with varying degrees of usefulness. Some conventions are a great help when working with a database. Others are just a big headache. When designing a data model, object names’ readability is an important consideration. A robot might not agree to this, as all names are equally easy for a robot to remember and to locate in a complicated SQL script.
Some people enjoy recycling houses, furniture, or cars. Why not also enjoy recycling databases? Imagine you inherit an old house. At first, that seems like good news: suddenly you own something that could be important and valuable. But before you celebrate, you might want to inspect the house carefully. See if it is structurally sound, if it has any foundation issues, if it is built to last... Once inspected, you might happily maintain it and even feel fortunate to have inherited it.
With age comes wisdom. Take it from someone who has spent a few decades dealing with databases, data models, IT guys, users, and software projects. “The greatest teacher failure is”, Master Yoda said. Decades of making mistakes with databases and data models – and learning from these mistakes – has proved to me that he was right. Yoda also said: “Always pass on what you have learned”. So here I am, passing on some of the lessons I’ve learned from tripping many times over the same data modeling stones.
Short answer: database modelers create the large and intangible structures that hold the information of an entire organization. Anyone unfamiliar with the work that database modelers do might think that they make a living by drawing pictures of boxes linked by arrows. Not quite. There’s a lot more to a database modeler’s job than creating beautiful schematic designs. They are also in charge of implementing those models, transforming them into operational databases, and maintaining the documentation so that developers and others can interpret, understand, and use the data architecture.