Oftentimes organizations assign the DBA group the responsibility for data modeling, in addition to the more conventional physical database management tasks that are well-known DBA responsibilities. Of course, that does not mean that DBAs are well-trained in data modeling, nor does it mean that DBAs are best-suited to take on the task of data modeling. An organization that is serious about data will create a data administration or data architecture group whose responsibility it is to understand the organization’s data. Data administration (DA) separates the business aspects of data resource management from the technology used to manage data. When the DA function exists in an organization it is more closely aligned with the actual business users of data. The DA group is responsible for understanding the business lexicon and translating it into a logical data model.
That said, 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. There is a popular folk story about four blind men and an elephant that helps to illustrate the purpose of data modeling:
A group of four blind men happened upon an elephant during the course of their journey. The group of blind men had never encountered an elephant before, but they were a curious group. So each blind man attempted to learn about the elephant by touching it. The first blind man grabbed the elephant by the trunk and exclaimed, “Oh! An elephant is like a snake – it is a long, slithery tube.” The second blind man reached out and touched the side of the elephant and remarked “No, no, the elephant is more like a wall – very flat and solid.” The third blind man was confused so he reached out to touch the elephant but poked his hand on a tusk, and he said “No, you’re both wrong, the elephant is more like a spear than anything else!” The fourth blind man grabbed the elephant by the leg and shouted “You’re all wrong, an elephant is very much like a tree – round and solid.”
Well, each blind man was right, but he was also wrong. The problem was not with the experience of each blind man, but with the scope of their experience. To be a successful data modeler you must learn to discover the entire truth of the data needs of your 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 process. 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 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 is fraught with many non-database-related distractions such as corporate politics and ROI that is hard to quantify.
But back to the basic topic at hand – data modeling. 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, a data model delivers value by enhancing communication and understanding, and it can be argued that these are quite valuable. But the primary value 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.
Another benefit of data modeling is the ability to discover new uses for data. A data model can clarify data patterns and potential uses for data that would remain hidden without the data blueprint provided by the data model. Discovery of such patterns can change the way your business operates and can potentially lead 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. To transition to this alternate way of thinking, follow these three “rules”:
- Don’t think physical; think conceptual – do not concern yourself with physical storage issues and the constraints of any DBMS you may know. Instead, concern yourself with business issues and terms.
- Don’t think process; think structure – how something is done, although important for application development, is not important for data modeling. The things that processes are being done to are what is important to data modeling.
- Don’t think navigation; think relationship – the way that things are related to one another is important because relationships map the data model blueprint. The way in which relationships are traversed is unimportant to conceptual and logical data modeling.
With all of the current hype surrounding Big Data and NoSQL and DevOps it is not uncommon for data modeling to become an afterthought, if it is even a “thought” at all. And that is too bad. Sure, it speeds up the development process… but what happens when somebody other than the developer wants to use the data? And use it perhaps in a different way or with a different access pattern?
The answer to being able to reuse data is proper data modeling and design.
Keep in mind that as you create your data models, you are developing the lexicon of your organization’s business. Much like a dictionary functions as the lexicon of words for a given language, the data model functions as the lexicon of business terms and their usage. Of course, this article just scrapes the tip of the data modeling iceberg. If you are a DBA with data modeling responsibilities I recommend that you find your way to a class, or if you cannot afford that, at least pick up a few good books on the topic.