Data Modeling Concepts Every DBA Should Know

By | In Database Administration | September 20th, 2016

Organizations often force the DBA to take on the job of data modeling. Unfortunately, that does not mean that the DBAs are always well-trained in data modeling, nor does it mean that DBAs are best suited to take on the task of data modeling. Oh, don’t get me wrong… some DBAs are great at data modeling… but many are not.

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 DBAs are doing the modeling, the most frequent slip-up is thinking physical too early in the process — this makes some sense because the DBA will be called upon to turn that logical model into a physical database eventually. But skipping to the physical implementation too soon is a surefire way to misinterpret business needs, miss critical requirements, and create a less than optimal database for your 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: Data Modeling Essentials by Graeme Simsion (Morgan Kaufmann, 2004); Mastering Data Modeling: A User-Driven Approach by John Carlis and Joseph Maguire (Addison-Wesley, 2001).

And do not skimp on the data modeling portion of your development projects. After all, understanding your data is the most important thing in the “information age”… right?

This blog was originally published on Craig Mullins’ blog at https://datatechnologytoday.wordpress.com/2010/12/06/data-modeling-concepts-every-dba-should-know/

Contact Us
Craig Mullins
Consultant at Mullins Consulting, Inc

Craig S. Mullins is working with Datavail and its DB2 practice to expand offerings. He is president and principal consultant at Mullins Consulting, Inc. and the publisher of The Database Site. Mullins has 30 years of experience in all facets of database management and is the author of two books: “DB2 Developer’s Guide” currently in its 6th edition and “Database Administration: The Complete Guide to DBA Practices and Procedures,” the industry’s only guide to heterogeneous DBA.

Leave a Reply

Your email address will not be published.
Required fields are marked (*).

2 thoughts on “Data Modeling Concepts Every DBA Should Know”
  1. Data modeling though, the expertise of Data Modelers, should not be necessarily separated from a core DBA function. A DBA, as has been often said has responsibilities for quite a number of functions along the data management value chain including responsibilities for both data modeling and translating such data blueprint into physical databases. Another text that I found recently in this area of data management expertise is: Database Design, Application Development and Administration by Michael Mannino. In addition, a DBA who has good background not only in data administration, but equally versed in object oriented programming (OOP) such as abstraction, encapsulation, polymorphism, etc. would be in better position at modeling data for his or her enterprise. While some large enterprises can still afford the separation of duties for DBAs, many enterprises today, especially in the era of cloud computing and database as a service, are requiring fewer DBAs, and that means DBAs must not only be thorough professionals and specialists, yet, they must wear many hats even more than ever before. In any case, most DBAs are fast becoming IT Developers as well, as the need to integrate into their core IT skill set: Java, JavaScript, REST, Application Development skills via leading IDEs, including Application Servers – Weblogic, WebSphere, etc. in managing the labyrinth of databases functions including core security architecture for mission critical transactions in a world racked by cyber threats and abuses by privileged super users. And gosh, DBAs must just not be able to perform-tune the database management systems only, dynamically create storage allocations, work seamlessly with top IT Developers and Architects, they are being encouraged to bring meaning to the data they help design by the ability to actually leverage the fundamentals of business skills and analytical rigor to present the whole picture to the executive board of the enterprise, and helping the board and CEOs to make the most intelligent decisions for their enterprises, a kind of business skills gained from top business schools. Thankfully, Oracle Corp. started encouraging DBAs more than 7 years ago for the need for them to also bag their MBAs in order to speak both the technical and business language fluently at the enterprise level, but most importantly in helping to help transform enterprises into highly performing and agile enterprises through intelligent data management and business analysis skills. If there is one beautiful illustration of this development recently, it is at Morning Star, the Chicago based investment research and management company where a former Data Analyst there would soon become the CEO. A DBA should prepare to function even at the C-Level of their organization with superior and broad based knowledge base as most organizations would require incisive data analysts more than ever. No DBAs should expect less in a very dynamic business world of 21st century where competition for deep knowledge capital assets across industries intensify more than before and one of the reasons Mr. Larry Ellison harped on the role of Artificial Intelligence (AI), in the current Oracle Open World, San Francisco, CA. AI has become a trend which is fast gaining currency in the global IT industry and across industries and DBA would be required to help build all necessary software algorithms and artifacts that would help fetch meaning from data being generated from machine learning, IOT, etc. pretty soon.
    Thank you and to the management and the cream de la cream of core Data Management professionals at Datavail for the series of unique and deep perspectives contents in expert data management value chain. But, I also miss you at TDAN, where I started reading your incisive articles about the US data management industry some years ago. Best regards, sir!

    1. Thank you for those thoughts and it is good to hear that we are in agreement! And thank you for the kind words re: TDAN… I enjoyed writing The Database Report column for them for many years.

      All the best,
      Craig