Can a developer read an entity/relationship diagram?

Can a developer read an entity/relationship diagram?

During a recent data modeling training class, someone asked based on my experience, can developers read entity/relationship diagrams? This question was not a jab to developers. (There were quite a few developers in the room!) This question was asked because in this organization, data modelers build data models using traditional Information Engineering (e.g. crow’s feet) type diagrams yet developers expect to see UML class diagrams. This is not the first organization where I have seen relational logical data models requested to be translated into object physical models. Should the data modelers build the physical UML diagrams? Or should the developers be trained in traditional entity/relationship diagrams? What are your thoughts?


  1. Greg Long 6 years ago

    Hmmm, good question Steve – and I’ve always wondered about the answer. The ‘Object Relational impedance mismatch’ is ringing in my head ever since I started (and I think failed) to translate the OGC Observations and Measurements schema to an ER model (Simon Cox abstracted the O&M to the max imho). Will there be a time when (ER) data modelers shift to OO? Probably. Keen to read other’s thoughts. GL.

  2. Vivienne Boogaard 6 years ago

    Data persists outside of the applications that use that data. With enterprise data, we may have many different needs for that data some of which involve the DSA (downstream applications – databases mainly). If a particular project needs an object model for their consumption of data in an existing physical database, then that is part of their usage needs but does not reflect how the data will always be consumed.

  3. Marco Wobben 6 years ago

    My obvious response is to “not prefer either”. As data modeling is meant to understand the issue at hand, which is a business oriented aspect. Any data model should represent that universe of discourse. Secondly there’s a need for some sort of storage, probably a database of some sort, and also some software to offer the stored data to the users of that data. To build a database and software aligned with the business issue at hand, more technical stuff needs to be tackled. To communicate the storage structure with software developers, two different type of gladiators come together in the same arena. They seem to talk the same business concepts, but are really both technically oriented. And technically oriented communication requires specific technical oriented communication. Specific communication for the database structures, and specific communication about the software internals. They align only to some extend, and therefor both are required. In working together in the same arena, it may help to have developers understand the database oriented models, and database developers may need to understand the developers needs, to better support them. We at CaseTalk start with a Fact Oriented Approach and kickstart database development and software development by automatically generating start models for database and software. So we really don’t prefer either, we prefer all three models.

  4. Ken Hansen 6 years ago

    Definitely an issue. A diagram may be worth a thousand words but different people read it differently and understandings are mixed. However it should be valid across technologies and the LDMer is not necessarily the best people to create all the process diagrams.

  5. Bruce W 6 years ago

    In some ways the more important question is can the business partner read an ERD. The LDM ERD is a model of the business data independent of the details of physical database implementation. Understanding of the business data is the starting point of good database design. If the data is going into a RDBMS, a PDM using the LDM as the starting point in a good first step in database design.

  6. Chris Raymond 6 years ago

    I reflect back on my previous experience coming from a lean background. If you treat any process as a virtual production line, then you start to see where your processes break down. You may be able to provide an excellent LDM to a developer, but if it doesn’t make sense to the developer, you’ve just produced waste on your virtual production line. (Arguably not waste, but if a recipient in your virtual production line doesn’t know what to do with what you’ve just provided, then you have an issue in the virtual production line.) Flip the coin. If a developer comes back to a modeler with UML, but the modeler doesn’t understand UML … again … waste in the virtual production line. In my lean experience I also learned that sometimes what it perceived as waste being produced in the virtual production line is actually just lack of training and/or lack of proper communication between segments of the virtual production line. If you are in a company where both disciplines are used, and it’s causing a breakdown in the “virtual production line” then both sides should get the training on both disciplines. It was an amazing experience to witness when one department finally understood that what they were producing for another department was almost useless to the receiving department.

  7. Andrew McBurnie 6 years ago

    Should the data modellers build the physical UML models? These model type are not directly equivalent. A UML model may also address significant aspects of process as well as data, so the possibility of additional requirement types is implied. We should first make sure the developers actually understand and accept, ie agree to implement, whatever models we are producing. UML models don’t have to be physical.
    I suggest that the key problem in many organisations comes before the data model/UML model issue. It’s the need for a development initiative to agree on the difference between business and physical models of ANY kind, and agree on all the requirement artefact types that are to be used.
    I’ve seen specs with E-R models thrown away, and the developer go off on their own frolic. This was a large government organisation, BTW, and it all ended in tears. (I was astonished that this was allowed, or not even realised.) Such a problem could equally happen with Object/UML models too. This is a significance governance issue to address before any initiative commences.

  8. Michael 6 years ago

    I am confident the development side of the house can understand anything put in front of them. The key thing is to ensure they understand what the model is intended to do. If they understand that, I have accomplished half of my mission. I normally ask before hand what they think an LDM is and how they think it will help them. That way I go in with some idea of how to present the results of efforts.

    There are some on the development side that already have made up their minds and you are not going to reach them. They think they have all the tools and the fact that many business partners believe nothing is getting done unless the development side is coding. And the development side of the house more often know this and use it to their advantage and we as data modelers are just left shaking our heads. The LDM captures the data the business thinks is important, how it can be used over time can change and that is fine. What I see is that once a LDM is delivered the PDM is less than 30% different when implemented, not counting Staging tables and Temp tables and even denormalized structures. Wish I had 60 – 70 percent of the work done for me in advance.

    If you bring the DBA and Dev Team early and let them see the model as it is being developed, your sessions/Presentations will go much better.

  9. Andrew Robinson 6 years ago

    I sometimes wonder if all of us only listen or read about 50% of what is presented to us. So it may not be the medium or the message but just the ability of someone to receive the information at the time. I do find though that people listen best when it’s more what they want to know – vs. what we would like them to know..

  10. John Giles 6 years ago

    Thanks to all those who have contributed already. Some great comments are there, including noting the needs of those who use the models, and whether the models are a reflection of the business logical persecutive or are intended to contribute to the creation of a physical data store. Now another twist I’d like to add to the mix, please.

    As background, I find it helpful to note that I can produce a data model using a number of different notations. As a somewhat crazy extreme, maybe I could produce a data model using some tool intended to capture electrical circuit diagrams. Sure, I’d have to explain my use (misuse?) of symbols for valves and transistors and what they mean for me, but the key message is the resultant model would still be a data model, even if I used a circuit diagram notation. Similarly, I can use Class modelling notations but I might still be producing what is fundamentally a data model.

    Let’s flip that around. Possibly the “developers” in Steve’s question are object-oriented (OO) programmers, and what they really want is nota data model, but rather, a class model, including all the richness to operations. Maybe they also want collaboration diagrams, state machine diagrams, etc.. In this context, they don’t want a data model using UML class modelling notation; they actually want a class model. And if that’s what they want, the data modellers will not only have to leaner a new notation, but also take on board the additional aspects of the OO way of thinking.

    So where do we go from here? If the OO developers want a data model but in a notation (UML) that they are more familiar with, we data modellers can learn their notation. David Hay’s book available from Steve should be considered, and if data modellers want a bit of a primer to the OO world (inheritance, operations & methods, polymorphism, and the like), my book, The Nimble Elephant, also available through Steve, has a chapter aimed at bridging the gap between a relational way of thinking and the OO paradigm.

    Alternatively, we can bridge the gap by offering the developers a bit of assistance with understanding our crows-feet and the like.

    A quick side note – if the end goal is a relational database, and we are modelling a physical view of the intended implementation, UML class models have a bit of trouble with some aspects. Conversely, if the end goal is a set of OO classes with their operations, data models are going to struggle. As noted by another contributor, let’s consider the user of our models.

Leave a reply

Your email address will not be published.