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.
You need data modeling to save yourself or your organization lots of money, hours, and issues. Read on to find out how data models do its magic. Data modeling is the process of creating a conceptual view of the information a database contains or should contain. As a result of this process, a data model is created, giving form to data objects (all those entities for which information is to be stored), the associations or relationships among them, and rules or restrictions that govern the information that enters the database.
Every software application uses stored data, whether it’s a simple list of user preferences or a complex database with a large number of tables and relationships. The importance of data modeling tasks within the software development life cycle is in direct proportion to the complexity of that stored data and its relevance to the application requirements. In the case of an application that only stores a list of user preferences, database modeling tasks are minimal and can be handled by practically anyone.
Do you have a database modeling interview coming up? Make sure to prepare to give yourself the best chance of getting the job! Find out what you’ll be asked in addition to “What are your strengths and weaknesses?” and “Where do you see yourself in five years?” So, you’re applying for a data modeling position...congratulations! It is a challenging job that involves great responsibility. Data modelers create a solid foundation for the information systems that manage the vital data of an organization.
You won’t go wrong with any of the titles reviewed here, provided you pick one according to your level of expertise. Database design began circa 1960, with the creation of the first database management system (DBMS). Since then, hundreds of books have been written and published on how to design effective and efficient databases for storing and retrieving information. There are all kinds of them: academic textbooks, books for a specific database product, introductory books for people outside the world of computers, among others.
A data model is more than just a pretty drawing that impresses users and stakeholders. When you add model validation to the design process, your data model can save you many hours of database-related work. When you design a data model, your ultimate goal is for the model to become a functional database. However, your model is basically a drawing, while the database is a not-so-flexible structure that holds information.