Data Modeling Concepts Every DBA Should Know

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 the task of data modeling. 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. 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 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 is fraught with many non-database-related distractions such as corporate politics and ROI that is 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, 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.

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.

• 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: Simsion, Graeme, Data Modeling Essentials, New York, NY: Van Nostrand Reinhold (1994); Carlis, John and Maguire, Joseph, Mastering Data Modeling: A User-Driven Approach, Boston, MA: Addison-Wesley (2001).