The introduction of object-oriented (OO) programming languages provoked an unfortunate schism in the world of software development. Relational databases dominated the database world and Entity Relationship (ER) modeling quickly dominated database design. This determined the target data structure for programmers when they wrote applications. However, OO languages embodied distinctly different views of data.
This mismatch might have been brushed under the carpet if object databases had ever gained traction, but they didn’t. They failed to dent the dominance of the relational database. In contrast, OO languages took off like a bank robber in a stolen Porsche. Not only did new languages like Smalltalk and Java emerge, but older ones like COBOL, Fortran and C evolved to acquire OO capabilities. Their dominance was soon as complete as the dominance of relational database.
Since that time, roughly 20 years ago, the software development world has been bedeviled by the Object/Relational mismatch, which has at its root, the reality that programming language and databases use distinctly different data models. OO developers and architects ignored ER modeling and employed the standard Unified Modeling Language (UML) to visualize the design of a system. Its class model unified object models between the wide variety of OO languages, but it never came within a mile of smoothing the mismatch between those objects and relational database structures.
Enter Embarcadero
Recently, Embarcadero bit the bullet and decided to bring peace between these two warring views of data. It was not a simple conflict to resolve because the two models have different goals. The ER model seeks to build databases that can be shared by multiple users and applications, whereas the UML model seeks to build applications with little regard to the general sharing of data.
If you view the world through a relational lens, there are three levels to a data model: conceptual, logical and physical. You think of data at the logical level in terms of entities and attributes, which form cozy relational tables. You neatly employ your data model to generate the SQL Data Definition Language (DDL) statements, which build the database for you. This makes perfect sense to data architects who model and design data flows and databases.
But if you view the world through an object lens you see it otherwise. The UML model has one level of data rather than three and defines data in terms of classes and associations, with classes able to inherit characteristics one from another. The data is modeled to serve the processes that act on it. These processes are captured in use-cases, sequence diagrams, statechart diagrams, activity diagrams and so on.
From the object perspective, when an application has finished working on an object, it chooses either to “persist” its data or not. That persisted data then, usually, becomes data stored in database tables. You can generate SQL DDL from Class diagrams, but you probably won’t end up with a database design that would make a data architect happy – and that’s the heart of the problem.
Embarcadero’s ER/Studio 2016 sets out to reconcile the two modeling approaches, and as far as we are aware, it is the only modeling product that does. It bridges them by introducing a new idea: Business Data Objects.
Learn more about Business Data Objects in the Embarcadero Deep Dive video (45 min).
Business Data Objects
From the relational perspective, a Business Data Object is a collection of recognizable business entities such as: Sales Order, Purchase Order, Customer and so on. Business Data Objects consolidate the entities you would encounter in an ER model (the logical model) such as Sales Order Header, Sales Order Line, Product, Supplier, Supplier Address and so on. From the object perspective Business Data Objects can be viewed as object classes.
The virtue of Business Data Objects becomes clear when you see how ER/Studio 2016 handles them graphically. You create them from an ER model by grouping together entities of the ER model so that every entity is included within just one Business Data Object. A simple example would be the grouping together of the Sales Order Header with the Sales Order Line.
ER/Studio thus provides a graphical representation of Business Data Objects, which can be expanded to reveal the logical ER model. This neat mechanism allows the modeler to work at two distinct levels, with Objects that have a clear business meaning and a clear application meaning (Business Data Objects) and with ER entities and their relationships.
Within a Business Data Object the modeler designates an “anchor” object, which is the central entity of the Business Data Object from a business perspective and from an object perspective. For a Sales Order it would be the Sales Order Header, for a Customer it would be Customer and so on.
Submodels
The power of Business Data Objects becomes clear when you consider an application context. In using ER models to create, say, a sales order entry application, developers will generally create a submodel (a subject area) including only the data entities directly involved. As applications, these submodels – possibly several per application – tend to proliferate to the point where there are hundreds. The complexity complicates the model and eventually entropy sets in.
Think of a submodel like this. A Sales Order Entry submodel for the sales order entry application may include the Sales Order Header, Sales Order Line, Product, Customer, Customer Delivery Address, Customer Discount Scheme and so on. Using Business Data Objects brings this under control. You create the submodel by selecting the appropriate Business Data Objects (Sales Order, Product, Customer). These Business Data Objects bring all the ER entities with them, allowing the developer to ignore and hide the ones he has no interest in. The upshot is that a Sales Order Entry Object will be composed entirely from the relevant ER entities in the data model. And these then define the data in the Sales Order Entry Object that will be persisted.
On the data modeling side of the equation, SQL DDL can be generated to target any platform from the physical model, which lies beneath the ER model. For collaboration between different development teams, the ER/Studio 2016 Business Data Objects and models can be published using Embarcadero’s ER/Studio Team Server.
In Summary
The resolution of the Object/Relational mismatch is an important achievement that will serve both data architects and application architects. However, the benefits spread beyond that. Being able to build a common data model means that it is possible to establish a common enterprise data model. This will serve business staff beyond IT in many ways. It will facilitate data governance and help staff better employ BI tools. It will assist the business analyst and even the data scientist. It will provide executives with a clearer model of the enterprise data resource and all its relationships.
About the Author
Robin Bloor, Co-founder and Chief Analyst of The Bloor Group, has more than 25 years of experience in software development, IT analysis and consulting. Robin is an influential and respected researcher and commentator on many corporate IT issues particularly in the areas of BI, information architectures and data management. He is a published author, having written a bestseller on electronic commerce entitled, The Electronic Bazaar, three Dummies books on IT, including SOA for Dummies, and his latest book co-authored with Dr. Gary P. Sherman, The Algebra of Data.
Learn more about ER/Studio Data Architect 2016 and Business Data Objects! You can also try it for free.