Thomas Frisendal - Graph Data Modeling for NoSQL and SQL: Visualize Structure and Meaning

I started my data modeling and database career right out of university in the 1980s. This was around the time that data processing was undergoing a technological revolution: relational database systems (RDBMSs) were becoming increasingly present in enterprise environments. There was controversy, with Dr. Codd evaluating commercial products against his relational model, and vendors adding relational layers onto their pre-relational products.

It was both a confusing time and an exciting time to be entering the data profession.

At that time, data modeling was virtually unheard of in enterprise IT. When Information Engineering became popular in the late eighties and early nineties, data and process modeling were the de facto methods for designing database applications. Naturally, the logical data models for discussing business requirements used the same notation; it made sense to use a notation that mimicked relational tables. Entity Relationship Diagrams (ERDs) are still the most common method for expressing business and technical models. With the advent of data warehousing and business intelligence for read-focused database uses, we made some changes to data modeling methods, but these remained relational notations.

Fast forward all these decades and we in the data world are facing another revolution with Not-Only SQL (NoSQL) technologies. These solutions (often called schemaless) came with promises of no modeling required. Yet the IT world is figuring out that we still need logical and physical modeling. These models dont necessarily specify the structure of data, but they do describe the meaning and known features of data. We also have a perfect storm of open source projects, cloud technologies, and global collaboration. The result is more than a handful of candidate database solutions. In fact, we now have tens of thousands of database types, versions, and distributions to choose from. Even so, we still use tools and methods that express themselves in relational models.

In this book, Thomas Frisendal raises important questions about the continued usefulness of traditional data modeling notations and approaches:

• Are ERDs relevant to analytical data requirements?
• Are ERDs relevant in the new world of big data?
• Are ERDs still the best way to work with business users to understand their needs?
• Are Logical and Physical Data Models too closely coupled?
• Are we correct in using the same notations for communicating with business users and developers?
• Should we refine our existing notations and tools to meet these new needs, or should we start again from a blank page?
• What new notations and approaches will we need?
• How will we use those to build enterprise database systems?

Frisendal takes us through the history of data modeling, enterprise data models, and traditional modeling methods. He points outquite contentiouslywhere he feels we have gone wrong and a few places where we got it right. He then maps out the psychology of meaning and context, while identifying important issues about where data modeling may or may not fit in business modeling. The main subject of this work is a proposal for a new exploration-driven modeling approach and new modeling notations for business concept models , business solutions models, and physical data models, with examples on how to leverage these for implementation into any target database or data store. These new notations are based on a property graph approach to modeling data.

I have a feeling well be seeing more of these proposals for helping data professionals navigate the data revolution we are experiencing. Its an exciting time.

Karen Lopez, Data Evangelist
Love Your Data, www.datamodel.com