Can a conceptual data model contain attributes?

Can a conceptual data model contain attributes?

I was asked recently to review a conceptual data model (CDM). My expectation was that the model would contain somewhere between 50 to 100 entities.

Upon entering the room and seeing the model for the first time, I realized my assumption was correct, as there were close to 100 entities. However, each of the entities on the model contained attributes! There were over 500 attributes on the model.

The facilitator stressed that this is a conceptual data model because all of the entities and attributes represent business concepts. The business created this model to capture their view of their business. The model was extremely well-organized for readability and there was very little abstraction as these terms were true business terms.

I was about to interrupt the facilitator and mention that this model is close to third normal form and is not a conceptual but instead a logical, but I kept quiet and listened to the rest of the background on the model.

I learned that the purpose of this model was to capture the business needs for a large initiative. Not requirements but needs. Needs and requirements are different. Needs focus on expression and terminology. Requirements focus on precision to solve a particular business problem, such as building a new application, reverse engineering an existing application, or defining the enterprise architecture for an organization. A need can capture the relationship between Student and Course, for example. A requirement would ensure that this relationship is precise, such as capturing whether that relationship between Student and Course is a Registration, Attendance, or Grade relationship.

The conceptual captures the business needs and the logical captures the business solution. This is how I teach it in my Data Modeling Master Class, where I define a CDM as:

A set of symbols and text that represents well-scoped concepts, along with their definitions and relationships, for a particular audience.

 

This model being reviewed, despite its detail, met this definition.

Once the needs were verified, then the logical was to be built. The logical would be precise and reality-based, meaning each attribute would be validated to make sure it exists in some source system and the model in general would be more abstract so that it can easily accommodate changes over time.

What do you think? Can a conceptual contain attributes? Please share your thoughts.

11 Comments

  1. Scott Kusky 2 months ago

    I agree, and so happy to see the focus on business needs, even if some of the detail begins to lead across strict definitions, it is critical to capture the business view so the best business solution can be achieved.

  2. Steven 2 months ago

    Yes, that is possible. Even necessary.

    See the ISO standard 9007 of 1986, and further work. Conceptually there are 8 concepttypes, of which 3 have to do with information (what you call data). One of these 3 is called facttype. This concepttype is the basis for what you call attribute.

    Your split between need and requirement is very interesting, and real. Today we really lack what you call need. This is the basis to be able to define information positions, and therefore very important to allow an organisation to own their information.

  3. Danny Greefhorst 2 months ago

    I agree with you Steve. I am currently defining a conceptual data model for the building sector in the context of the environmental planning act. A lot of terminology is formally defined and/or used in laws and regulations. This terminology goes much further than object types; it goes down to the level of attributes. It would be strange not to include these in my conceptual model. I will probably have multiple diagrams, with varying levels of detail for various stakeholders.

  4. Nic Jefferis 1 month ago

    Any mode that helps the business understand the information they need in data terms helps the communication for development, maintenance and operation of systems. The adoption of attributes may help that understanding, the differences between entities and attributes, and not to lose anything said in the model development. Surely its better to have some examples to explain what the concept covers rather than say a model has to be exactly this to fit into the conceptual box.

    • Steven 1 month ago

      Conceptual modelling has nothing to do with IT, while it is IT that discusses. CM is not to help understand a given world, in CM called Universe of Discourse, it is to help organisations to know the information they need to further the knowledge they need to do what they need to do. The result is not a set of tables and columns, it is a description of the data, the facts, that is their information. When you use the right technique for this, for instance, normalisation is implicit.
      But in practice IT is modelling, and squabbling about what such a “model” may contain, with opinions about normalisation, numbers of entities etc. This is not the discussion that is needed.
      The question is about information and their owners. What they need. So whether you may have “attribute (types)” or not is in fact a non-discussion.

  5. Thomas Frisendal 1 month ago

    Hi Steve
    Good question – this discussion is somewhat overlooked. In fact many development teams have adopted an approach one could call: “The Great Pragmatic and Quick, Unified Data Modeling Practise”. It is a one-step process performed when necessary in the development process. The result is that logical and physical “came together”. The driving force is time to delivery, and what the “unified” process is trying to answer are the “what” and “how”, not the “why”.
    Conceptual level modeling is based on business concepts. And there are frequently both structural and semantic differences between the business-facing (“conceptual”) model and the solution-oriented logical model. And that is how it should be. Logical modeling is a design process, which implies design decisions, scoping / de-scoping, changing business practises and what have you.
    So, I agree with the facilitator.
    Somebody should develop a business modeling layer, non-technical but visual, with floating transformations to logical structures. Sort of a visual business vocabulary with concepts and properties. I propose, as you know, that the Property Graph Data Model has the power to unify concepts and logical models. It is all in my book on Graph Data Modeling, available on Technics Publications! 🙂
    /Thomas (@VizDataModeler)

    • Steven 1 month ago

      Hi Thomas,
      Agree. Since the 70’s there has been a quite different approach to conceptual modelling than the ERD technique we use today. The focus is not on attributes but on objecttypes, facttypes and constrainttypes. The objective is not to create a logical model, as you are right to remark. The objective is to know your information, so an organisation is able to manage what they need to know to be able to do their business. Having and maintaining such a conceptual model, naybe adding functional and behavioral concepttypes, really allow organisations to control what they want and need. Including IT solutions, even up to the point scrum/agile projectwork is much less necessary because a lot is already known.

      By the way: it is usually quite easy to “translate”a really good conceptual information model to a proposal for a logical information/data model, in practice having a better result than a more than 5th normal form. The real challenge is to make the organisation the real owner, and to drop all kinds of influence from IT solution pushers. It’s about getting the organisation in charge of their IT contractors. This solves many problems.

  6. Jan van Til 1 month ago

    Can a conceptual information model contain entities?

    • Steven 1 month ago

      Hi Jan,
      Well, there is a problem with terminology. One of the 8 concepttypes is called objecttype, entittype or has another name ( I’ve heard of thingtype, even). Depends on what you mean by entity, but it may be of this concepttype, so an entity belonging to the entitytype X.

  7. Chip 2 weeks ago

    As in all things there is little black and white and whole lot of grey … I think of Steve’s CDM as one that is at the end of the CDM spectrum nearest an LDM. I can see where some might be inclined to call it an LDM … but I’m comfortable identifying it as a CDM per the observations above: Needs (CDM) vs requirements (LDM) … though these can be pretty tough to distinguish at times … and biz-facing (CDM) vs tech-facing (LDM).

    Attributes in a CDM … I’m used to seeing a few, so I have no problem with that. This model is just further over in that spectrum … with a surprisingly high number of attributes!

  8. George 2 weeks ago

    Stephen,
    I specifically agree with your follow-up to Thomas in establishing the organization as the ongoing owner of the model. A detailed CM (with business authorship) will more likely connect to the LM which should bring organization adoption and ownership more easily. High-fives to the organization to drive to a level of detail of needs that will supports the evolving requirements.

Leave a reply

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

*