All too often I see organizations forcing the DBA group to take on the job of data modeling. Oh, perhaps it is not a formal requirement, but it happens nonetheless because there is no staff focused on modeling data. So the DBA does it—perhaps not very well—just enough to be able to create a sound database design. And, of course, the DBA retains all of his other duties! Data modeling just gets squeezed into the long list of conventional database management tasks that are well-known DBA responsibilities.
Perhaps, this practice is more commonplace today because of the somewhat cavalier attitude that many IT professionals take with regard to data. It is not uncommon for systems analysts and programmers to think that the data model should be “flexible,” meaning that they shouldn’t be forced into a rigid schema. This is sort of the NoSQL mantra.
So if the schema is changing “on-the-fly,” why would you even want to model the data up-front? Well, as with most things, the devil is in the details. Sure, I suppose that there are some viable use cases for having flexible schemata. And these use cases are more common in big data, social media, streaming web content type of applications. But do not misinterpret what I am saying: The vast majority of databases and applications benefit from a well-thought-out and enforceable schema. The applications that run the world—banking, financial, insurance, manufacturing, travel, etc.—benefit from data modeling that translates to a sound database schema.
And, even a flexible schema can benefit from a sound model of the data it houses. Becoming too flexible can result in a pile of rapidly growing, unstructured, bad data.
An organization that is serious about data will create a data architecture (or data administration) staff whose responsibility it is to understand the organization’s data.
The data architect or data administrator (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 and translating it into a logical data model.
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.
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.
To be a successful data modeler, you must discover the entire truth about the data needs of your business.
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.
Keep in mind that as you create your data models, you are developing the lexicon of your organization’s business. Similar to the way that 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.
Only by understanding the business, and how we communicate with each other about that business, can we ever hope to build useful IT systems.