Organizations often force the DBA to take on the job of data modeling. That does not mean that DBAs are well-trained in data modeling, nor does it mean that DBAs are best suited to take on this task. The data administration (DA) team is best suited for modeling data. This is because data modeling requires knowledge of the business aspects of data resource management.
When the DA role exists in an organization, it is more closely aligned with the actual business users of data. It may, or may not, be called data administration these days though. The group may be called data architecture, data management, data resource management, or even data governance. Regardless of its name, the DA group is responsible for understanding the business lexicon and translating it into a logical data model.
That said, DBAs are more technology-focused than business-focused. That does not mean that the DBAs are completely ignorant of the business purposes for the data they manage, just that their primary focus is the technology of managing the structures used to store and access data.
Nevertheless, many organizations lump DA and DBA together into a DBA group. As such, the DA tasks usually suffer. One of these tasks is data modeling. To properly design data models requires an understanding of the entire truth of the data needs of the business. You cannot simply ask one user or rely upon a single expert, because his or her scope of experience will not be comprehensive.
The goal of a data model is to record the data requirements of a business function. The scope of the data model for each line of business must be comprehensive. If an enterprise data model exists for the organization, then each individual line of the business data model must be verified against the overall enterprise data model for correctness. An enterprise data model is a single data model that comprehensively describes the data needs of the entire organization. Managing and maintaining an enterprise data model are fraught with many non-database-related distractions, such as corporate politics and ROI that are hard to quantify.
Data modeling begins as a conceptual venture. The first objective of conceptual data modeling is to understand the requirements. A data model, in and of itself, is of limited value. Of course, since a data model delivers value by enhancing communication and understanding, it can be argued that these are quite valuable. But one of the most significant purposes of a data model is its ability to be used as a blueprint to build a physical database.
When databases are built from a well-designed data model, the resulting structures provide increased value to the organization. The value derived from the data model exhibits itself in the form of minimized redundancy, maximized data integrity, increased stability, better data sharing, increased consistency, more timely access to data, and better usability. These qualities are achieved because the data model clearly outlines the data resource requirements and relationships in a clear, concise manner. Building databases from a data model will result in a better database implementation because you will have a better understanding of the data to be stored in your databases.
A data model can clarify data patterns and potential uses for data that would remain hidden without the data blueprint the model provides. Discovery of such patterns can change the way your business operates, potentially leading to a competitive advantage and increased revenue for your organization.
Data modeling requires a different mindset than requirements gathering for application development and process-oriented tasks. It is important to think “what” is of interest instead of “how” tasks are accomplished.
- Think conceptual—focus on business issues and terms.
- Think structure—how something is done is not important for data modeling. The things that processes are being done to are what is important to data modeling.
- Think relationship—the way that things are related to one another is important because relationships map the data model blueprint.
As you create your data models, you are developing the lexicon of your organization’s business. If you are a DBA with data modeling responsibilities, I recommend that you find your way to a class, or at least pick up a few good books on the topic. The following books are quite good (but there are others):
- Data Modeling Essentials, 3rd Edition, by Graeme Simsion and Graham Witt (Morgan Kaufmann, 2004)
- Mastering Data Modeling: A User-Driven Approach by John Carlis and Joseph Maguire (Addison-Wesley, 2001)
- Data Modeling Made Simple, 2nd Edition, by Steve Hoberman (Technics Publications, 2009)
DBAs will do themselves a favor by becoming more well-versed in the business meaning of their company’s data. Learning how to model data effectively can go a long way toward making that happen!