Business Data Modelling

Business Data Modelling - the method

Like any method, Business Data Management comprises a way of thinking, a way of working and a way of writing. For Business Data Management, the way of thinking is considered the most important element of the three. And most difficult to explain. Consider the way of working and writing presented here as suggestions and feel free to replace them with your own practises, as long as it supports the way of thinking and the goals set for Business Data Management.

Business Data Modelling - definitions used

Before we start to explain Business Data Modelling we have to make the terms we use clear. Within Business Data Modelling we also should use the right terms in a consistent way and provide definitions. The following terms are used:

  • Business: Business is the activity of buying and selling goods and services from a professional perspective (for example: Banking).
  • Business term: A Business term is any term used by at least multiple people within the same business, with the purpose of understanding each other better when exchanging information (verbally, in writing, electronically).
  • Business concept: A Business concept is a Business term which is a kind of thing that is necessary to run the Business (for example: Customer, Contract).
  • Business object: A Business object is a thing that is necessary to run the Business (for example: Customer John Baker , Contract 123456789). Business objects that behave identical are grouped as a Business concept.
  • Business concept relationship: A Business concept relationship is the coherency between two (or the same) Business concept(s) explaining the behaviour of the Business objects between these Business concepts (for example: Customer is holder of Contract).
  • Business characteristic: A Business characteristic is a Business term which is a descriptive term of a Business concept (for example: Country code, Customer first name, Fair value).
  • Business characteristic domain: A Business characteristic domain is a limited set of Business characteristic values which are applicable to the Business characteristic.
  • Business rule: A Business rule is a directive that has to be applied on Business terms to control the right definition, use or format of the Business term (for example: to apply a certain Business characteristic domain, that a certain percentage by nature cannot be more then 100, how an IBAN must be formatted, etc.).
  • Business characteristic value: Business characteristic value is a single unique value allowed within a Business characteristic domain to which all Data values of the Business objects have to comply.
  • Business characteristic value term: Business characteristic value term is a Business characteristic value that is important enough to the Business to be considered a Business term on its own (for example: Accepted Agreement as a value of Agreement Life Cycle Status Type, UCR2+ as a value of UCR Rate).
  • Data value: Data value is the value assigned to a Business characteristic at the level of a single business object. In case the Business characteristic has a domain specified the Data value has to comply to the domain that means that the Data value applied should be within the collection of Business reference values of the Business characteristic.
  • Business concept identifier: A Business concept identifier is a Business characteristic or a group of Business characteristics of a Business concept with the special feature that it will have no duplicate Data values for the different Business objects within the Business concept.

Business Data Modelling - the steps

Business Data Modelling is the function to create the Business Data Model. Because this is an extensive work, it will be done in bits and pieces. Even if there are several “Businesses” to identify within an organisation, modelling a single Business may take multiple development circles, multiple months or years to create the model for the entire Business. On top of that, new insights or a learning curve may result in rework on the model already validated by the Business owners. This rework will actually never stop because of the two reasons given but mainly because Business will always change. All fragments of the model created or modified will be integrated by the Business Data Administration function that will also be the guardian of the model.

Within regular Data Management, often an ICT project is the initiator of creating data models needed as part of the solution. If Business Data Management is well accepted within Business and ICT, the Business could create or extend an existing Business Data Model for the purpose of implementation and Business functionality needed. One could consider the Business Data Model being part if the Business requirements, explaining how the Business operates. So a project could be the reason for the Business to do their homework. The Business Data Model should be there, “ready” before the ICT project starts of. That is why we do not plot the steps of developing the model on regular Project Management or Scrum/Agile within the ICT cycle. That does not mean that Business Data Modelling could not make use of these principles, (re)developing a (part of a) Business Data Model could well do with a project-based approach.

The need to start Business Data Modelling may well be the end of an ICT project, because information delivered is not correct. Or because the Business cannot verify the correctness of information because of the complexity of accounting data and processing of this data to information involved.

The best reason is that business parties themselves start to recognise that they do not speak one language, and/or that their language is not in line with documents, folders, website, etc. Or that they find difficulties in explaining (strategic, tactical, operational) changes. A Business Data Model will help communication horizontally within the Business, vertically between the different levels within the organisation and to other business parties within or outside the organisation.

So there may be different incentives and reasons to start modelling a certain area of the Business. The approach and steps needed may differ from each modelling activity. Considering the content of what is to be delivered within a Business Data Model, development may include the following steps:

Define terms – Model concepts – Model characteristics

and:

Model identifiers – Relationship modelling

Business Data Modelling - step 1: Define Business terms

Business Data Management is developed to define and model the business in order to get the semantics of the Business clear. Business terms are the centre point of the study, they are discussed by business representatives, named, defined and classified into Business concepts, Business characteristics and in some cases Business characteristic value terms.

To create context, always start to name and define the Business you are modelling for. The term “table” could be a Business term for a furniture maker, it is not very likely a Business term within banking. The Business will give context to the Business term, its name and definition. A table within the context of the business “furniture making” is different from a table within the context of the business “IT”. Where we should try to avoid homonyms and synonyms within a single business, we know for sure that this will occur if we do not model within the context of a business.

For each Business term that pops up, the first thing to do is to find or determine the Business and Business owner and their related parties. Because these are the business managers (or their subordinates who represent them) who have to be involved in naming and defining the Business term. Take into account that during this process any meta data owner can decide to change the Business term, the name and its definition. For example in case the synonyms Agreement and Contract are both used, it can be decided that the Business chooses for Agreement and that for example the Business term Contract date is changed to Agreement starting date. Additional actions must be taken to support the Business in changing their language, documents, folders, etc. Creating a proper definition is an art on its own and should be accompanied by clear Business Data Administration guidelines. There are guidelines behind the definitions given in the previous section of this page.

Within Business Data Management, all Business terms are relevant and modelled. Where in traditional data modelling derivable or calculated data fields usually are left out of the data model, Business Data Management takes all Business terms in. Because they are a Business term, they are used within the Business, the meaning should be clear for everyone. Like for example Order value. Is it an amount of money? In which Currency? On which prices and discounts is it based? How are returned goods settled within this value? Etc.

Business terms will always need a name and definition but other meta data may be relevant to really document and make the Business term explicit:

  • Additional Comments or Remarks, to have it separate from the definition.
  • The plural of the Business term. 
  • The abbreviation of the Business term. For example the Business term Uniform Counterparty Rating may be better known by its abbreviation UCR.
  • Different naming of the Business term outside the Business, relevant to the Business. Like used by joint venture parties, regulators, etc.
  • Business rules like that a Date of birth of a Person must be in the past or that a Term Loan can only be granted if the Customer (Borrower) has a Bank account within that same Bank, etc.
  • Derivation or calculation rules. It is a special kind of Business rule but they are important enough to be mentioned specifically. Like if you have a starting date and an end data, the period can be calculated. Or you have a starting date and the period, the end date can be calculated. Do not make a choice in which Business term is derived or calculated, just explain the coherence from Business perspective and take them all into your Business Data Model.
  • International operating companies may have the need in creating a lexicon in different languages. To document that Customer will be Cliente in Italian and Kunde in German. Be aware that this may not be just a matter of plain translation, the names are the Business term names as used in the local languages. And some Business terms (words) may have no equivalent in a different language or may have a different meaning. For example do not be surprised that what an Englishman will call a “lake”, not always will be named a “lac” by a Frenchman or the other way around. Definitions and other meta data in other languages are often avoided because it a lot of work and it is hard (if not impossible) to create identical semantics in a different language. But Business Data Management promotes the lexicon as an actively used reference book and if needed, the multi-language version of the lexicon should be developed and promoted.
  • For Business terms that end up as a Business characteristic:
    • Type. For example is it a percentage, a factor, amount of money, a count, a number, a date, a period, etc. It might be obvious but the Business should make it clear. You might be surprised discussing this topic, that different business experts have different preferences like using a percentage in one report and using a factor for the same Business term in another one. Making it clear and if needed setting a standard, really helps good semantics!
    • Format. Think of range and size here. For example, there are percentages that by definition always will be between 0 and 100. Other ones can be negative, of can go over 100, etc. Sounds like modelling data? Yes, it is often done but within Business Data Modelling it is claimed by the Business to specify how the Business characteristic looks like. At the same time we stay out of discussions on how to store the Data values of the Business characteristic within an accounting system.
    • Representation. Business should create the standards for this. Like how do we want to present an IBAN? How do we want to present an amount of money?
    • Unit of measurement.
      • (1) Within Business Data Modelling you can choose to express the unit of measurement within the definition. Like the distance is measured in meters (or kilometres or miles, etc.).
      • (2) Another option is that the unit of measurement is expressed in the definition, but as a reference to another Business term. For example that the definition of Transaction amount states that it is expressed in the Currency of the Agreement.
      • (3) Unit of measurement can also be made explicit as meta data. That will mean that for example the Business term “Distance” will have a name, a definition but also the unit of measurement to state which unit is standard for this Business term. 
      • (4) If the Business cannot make the unit of measurement explicit and fixed for a Business term, the Business term should come with another Business term that expresses the unit of measurement. For example that the Transaction quantity is always accompanied by Transaction unit of measurement. So for each Business object within the Business concept, a different unit of measurement is applicable. This way, Business terms can be connected (on meta level) and they only give the proper meaning when they are interpreted integrally.

Studying the above given definitions, one can see that definitions and other meta data hold references to other Business terms. If possible, tooling used for creating and maintaining a lexicon that supports the use of hyperlinks to other Business terms will be a great advantage. That way the modellers are sure that they use an existing and properly written Business term within their meta data and secondly, if a Business term will have a change in its name, the related texts and other references will remain in sync. In this case, having the plural versions of  Business terms and being able to use them in definitions and other meta data, will improve the readability of it. References within the meta data of Business terms will be the basis for the modelling exercise in the next step.

Business Data Modelling - step 1: Define Business terms - domain and value

When defining Business terms, it is of great importance to give examples. A few examples may tell more than a thousand words.

For Business terms that will be Business concepts, some examples that everyone knows of (largest customer, biggest contract) will give clarity in case of any doubts.

For Business terms that will be Business characteristics, there are two ways of giving the examples. In case the Business characteristic could have just any Data value for each of the Business objects, some well known examples may give additional clarity. Like the actual address of an important customer, the actual holding company of the subsidiary of your company, etc. In case there is a limited set of values applicable to the Business characteristic – that is: a Business characteristic domain – these Business characteristic values must be made available by supplying the full list.

Some Business characteristic values are that important to the business that they are a Business term on their own. Like UCR+ as a value of UCR Rate. Each of the Business characteristic values of UCR Rate will have its own meaning and definition. One could give examples of this, but like for the UCR rate, the examples my not apply anymore after a period of time. So be aware not to give examples that require lots of effort to maintain within your Business Data Administration, unless it is critical.

Business Data Modelling - step 2: Model Business concepts

Business terms from the lexicon will end up as a Business concept, a Business characteristic or a Business characteristic value term. And we have seen that definitions and other meta data of Business terms hold references to other Business terms. Let’s first focus on Business concepts. They have definitions that often relate to other Business concepts. For example a definition of “Term Loan” might state that it is granted by a Bank to a Customer. These Business concept relationships can be named and (if needed) explained:
• Bank is lender of Term loan
• Customer is borrower of Term loan

As you see, the name of the Business concept relationship will incorporate the names of the Business concepts. A second name for the Business concept relationship can be added, stated from the other direction:
• Term load is lent by Bank
• Term loan is borrowed by Customer.

Beside the name, there are a few characteristics on Business concept relationships to study in the real business world. And because a Business concept relationship connects two Business concepts, each characteristic has to be considered both ways:

  • Cardinality: the quantitative characteristic of the Business concept relationship. For Questions like “can a Customer be the borrower of just one Term loan or can it have multiple?” and “can a Term loan be borrowed by just one Customer or can there be multiple Customers?”
  • Optionality: concerns the possibility of the absence of (each side of) the Business concept relationship: “can we have a Customer that does not have a Term loan?” and “can we have a Term loan without having a customer being the borrower?”
  • Duplicity: states in case of a multiple cardinality, whether or not these multiple Business objects are always all different ones or that the same Business object may occur multiple times. For example, if you disassemble a car into parts, (Car consists of Parts) it is likely that the single part “Wheel” will not occur once but 4 or (in case of an identical spare wheel) 5 times.

Cardinality is the most relevant characteristic for each side of the Business concept relationship: is there one or can there be multiple? Optionality adds the possibility of absence of each side of the relationship. So if cardinality is one, does it always has to be one (1) or can it be zero or one (0/1)? For example, if you rent boats, a boat can be rented out or not. But a Term Loan cannot be without the Borrower. Als0, if cardinality is multiple, does it always have to be at least one (or more: 1..N) of can it be zero, one or more (0..N)? For example, an Order should have at least 1 and may have (preferably) multiple Order details. But a Project may not have a Project member yet during planning phase. Later on, there may be multiple Project members assigned to the Project.

Duplicity is often forgotten but can be essential in business practice. For example, do we have Orders that can have a single Article on multiple Order details or should all Order details have all different (ordered) Articles specified? Or suppose you have the multiple – multiple Business concept relationship between Project and Employee: will there always be all different Employees on the Project members list or can a single employee be listed twice or even more times on a single Project members list? It will have consequences for example on the meaning and modelling of Project roles within this context.

The Business concepts and their Business concept relationships are an essential part of the Business Data Model. The Business concept relationships with their Cardinality, Optionality and Duplicity (COD) for each side of the relationship, give real insight in how the Business works and better: how the real world of the Business looks like documenting leeway and constraints.

The Business concepts and their relationships can be visualised by means of a so called Entity Relationship Diagram (ERD) which is commonly used for data-related modelling. If you use this modelling technique, make clear on the diagram that it is a Business Data Model. Make sure that the diagram visualises the proper Business concepts by their names, the Business concept relationships by their names and the Cardinality, Optionality and Duplicity (COD) for each side of the relationship.

For the Business concept relationships: Please notice the < for multiple and the absence of this at the single (1) side of the relationship. And please notice o for optionality placed on the relationship there where it is valid. 

Do be aware that this way of “writing” is just a suggestion.

A few remarks. 

(1) Note the importance of well-defined Business concepts: they mostly hold related Business concept names and are therefore the basis of modelling the real business world. Making the Business concept relationships explicit and visualising them into (e.g.) an ERD, may lead to the awareness that definitions must be improved giving the need to partly redo the modelling process. 

(2) Above we stated that a Business concept relationship will have a (primary) name and may have a second name stated from the other direction. In case of the (most common) 1 to multiple cardinality, state the name from the 1 to the multiple direction. The second name may be from the multiple to the 1 direction (as in the example above). In case of a multiple to multiple or a 1 to 1 cardinality there is obviously less need to consider a direction, distinguish between the two names or even to add the second name of the Business concept relationship.

(3)  Some people find it hard to do Optionality and Duplicity or even the full COD. You could decide to do them later but realise that you are missing insights which may result in remodelling in a later stage when adding the COD to the Business concept relationships. 

Business Data Modelling - Model Business concepts - extended

There are a couple of attention points in modelling Business concepts.

Subtypes: Sometimes you can break down a Business concept into other Business concepts. For example Vehicle into Truck, Van, Car. A breakdown can be relevant in case subtypes have Business characteristics not applicable for other subtypes and/or in case subtypes have Business concept relationships not applicable for other subtypes. In general: in Business they do not behave exactly the same. For a truck or a van the load capacity in terms of maximum weight and volume may be relevant for the Business, for a car it may be the number of seats. Model all in the ERD, showing that the breakdown is relevant for the Business. Relevant is that subtypes are “Business concepts within a Business concept” and that they have the purpose of creating subsets of Business objects within the overall Business concept. Subtypes exclude one another. So a Business object is only member of 1 subtype (a vehicle is a truck OR a van OR a car). But be aware that there can be a hierarchy of subtypes, a multi-level breakdown where Business objects are (ideally) assigned to (characterised by) the lowest level only by which they are automatically also a member of the higher level(s) of subtypes (a car is always a vehicle, a vehicle is not always a car).

Roles: Special attention is needed for the phenomenon “role”. In examples above the terms Person, Customer, Lender, Borrower are used. No one is born a Borrower but when you take a Loan from a Bank, you will have that role. So first, group business objects into what they are and not in what role they play. Your roles may change often, but you will still be the same Person. Roles primarily come from Business concept relationships. If you say:

“Person is borrower of Term loan”, you know that Borrower is a role that a Person can have.

“Person is bank account holder of Current Account, you know that Bank account holder is a role that a Person can have.

These are examples of “single” roles and it is clear that it is a role of Person. We speak of a double role in case of a role on both ends of the Business concept relationship like:

“Person is employed by Organisation”, we could identify the role Employee on Person and the role Employer on Organisation.

There can be a breakdown in roles, like we have discussed in subtypes. A breakdown can be relevant in case roles have Business characteristics not applicable for other roles and/or in case roles have Business concept relationships not applicable for other roles. In general: in Business they do not behave exactly the same. In fact we have here identical reasoning as for subtypes. We could say that any Person who is a Borrower and/or a Bank account holder is a Customer. A Person can be a Customer but perhaps not. Roles are modelled as Business concepts, but remember that roles must be based on Business concept relationships. Roles do NOT exclude one another. So a Business object can have multiple roles (a Person is a Bank account holder AND a Borrower).

Subtypes and Roles: We often see that the breakdown in Subtypes and the breakdown in Roles are not on their own but they interconnect. For example, if you have the role of Father, this can only be so if you are of the subtype Man of the subtype Natural Person of the Business concept Person. An integral scheme of subtypes and roles can be quite clarifying and add significantly to the Business rules needed.

We leave the examples mentioned before as they are, but if you came reading this website this far, you will know you can do better!

Business concept relationships: multiple to multiple. Most relationships will have the 1 to multiple cardinality. But you can also run into a multiple to multiple relationship between Business concepts. In that case having relationship names stated from both sides of the relationship, makes more sense. For example between Project and Employee:

Project has project member Employee / Employee is project member of Project

You can already see from the relationship names that there is something as a Project member which can be considered to be a Business concept on its own. With the third Business concept in place, we get two 1 to multiple relationships:

Project has assigned Project member / Project member works for Project
and
Employee is assigned as Project member / Project member is fulfilled by Employee

Reasons to model with the additional Business concept is that it is a Business term on its own with probably dedicated Business characteristics and perhaps also additional Business concept relationships, apart from the two already mentioned. Another strong reason to split a multiple to multiple relationship into two one to multiple relationships (while adding the additional Business concept) is in case of the business need for Duplicity, on a single side or both sides of the multiple to multiple relationship. Why, when and how it occurs is of business relevance and should be examined and Business rules made clear. Splitting the multiple to multiple relationship might give better insight but not always necessarily. Finally, one could argue that Project member is needed as a Business concept because it can be (in this case) considered a role of an Employee.

Make sure you take either the multiple to multiple Business concept relationship OR the additional Business concept with the two 1 to multiple Business concept relationships.

Note: As we name the Business concept Project member from the Business concept relationship, also consider Project member as a subrole of the role Employee.  In case of deployment of external interim staff as Project member, Project member may be a subrole of multiple roles in case the definition of Employee does not include External staff. 

Business concept relationships: 1 to 1. You can also run into a 1 to 1 relationship between Business concepts. If they are really named as two different Business concepts, study it and find out if they are not the same (synonyms). It may be different if we talk of a Business concept relationship from and to the same Business concept:

Person is married to Person

Another situation can be that the 1 to 1 relationship co-exists parallel to a 1 to multiple relationship. Suppose we consider the Project manager a Project member AND we allow only one Project manager per Project, we could add the 1 to 1 relationship:

Project has project manager Project member / Project member is project manager for Project

In case also other Project roles are relevant for the Business, Project role will be a Business term and Business concept on its own which would give another result.

Business concept relationships: Redundant relationships. Be aware of redundant Business concept relationships that add no information. In case of a hierarchy it is quite clear. If you model the city of Chichester within West Sussex and West Sussex within England, there is no need to state that Chichester is within England. In terms of Business concepts, if you have the Business concept relationship between Country and County and also the Business concept relationship between County and City, the Business concept relationship between Country and City is redundant in case of the same Business meaning as a geographical breakdown.

Products. Products are often subject to confusion and misunderstanding. Suppose you want to order the book Elon Musk by Ashlee Vance. You do not ask for a specific copy so here “the book” is something else than “the book” that I hold in my hand. So we could model “Title”, which we order and we receive a single copy, a “book” the following day. But are we consistent in this? When I present a single copy of a book to someone else and ask “did you read this book”, we do not mean to ask if this person actually read the specific copy, we actually want to know if that person read a (just any) copy of the title. It is the same for the examples above on Term loan. Term loan could also be a product from the catalogue, and a bank could sell it a million times. So do we define Term loan as a kind of product, where Term loan will be one instance of Product or do we define it as a Business concept for the one million copy’s or specimen of the product type, granted to Customers?

Priorities. Modelling your business may take a long time and maintaining it is something you have to do as long as your company exists. So where to start? Previous point on Products shows that this really has to be clear before we can do sales, transactions, etc. In general, we should have more static concepts clear before we can properly add more transactional kind of Business concepts in the model. The “static” ones are for example Product, Customer, Production Facilities, Markets and Channels, Employees, etc. Transactional will be the day-to-day buying and selling, incoming and outgoing of goods and services and financials which will relate to the Business concepts which are referred to as more “static”.

Business Data Modelling - step 3: Model Business characteristics

Now that we have a diagram of the Business concepts and how they relate, we could start assigning Business characteristics to the Business concepts. Within Business Data Modelling, we suggest that a simple list of Business characteristics per Business concept is quite adequate. For example if Business needs to know the first name, middle name, last name, title, date of birth and address of any Natural person, this list for this Business concept will be fine in case each Business characteristic has proper meta data.

What may happen is that there is a Business characteristic that is applicable to multiple Business concepts. In some cases, it needs to be split and made specific for each Business concept. For example for the Business term Starting date which you may need for Event and for Agreement. Replacing the term by two separate Business terms, will make the definition less generic, more explanatory. There may be different Business rules to follow for the two.

But suppose you have the Business term Fair value? Business may claim it is a single Business term with a single definition that is applied to all kinds of assets and liabilities. In these kind of cases, a single Business term may “explode” into multiple Business characteristics to different Business concepts. In order to know which one you talk about, we suggest to create a specific Business characteristic name that is a concatenation of the Business concept name and the Business term name. For example the Business characteristic name “Term loan fair value” that links to the Business term name Fair Value and is listed for the Business concept Term loan. Try to prevent to duplicate the Business term definition to the Business characteristic level (with a small alteration perhaps). It will make it hard to maintain. Suppose the Business term definition speaks of (in general) the value of any asset or liability, you may add a comment on the Business characteristic level that it concerns the specific Business concept it is listed for plus additional remarks, if needed.

At step 2 we have discussed the phenomenon “role” of Business concepts. We saw that these are related to the meaning and naming of Business concept relationships. Like in “Person is borrower of Term loan” you know that Borrower is a role that a Person can have. This principle may apply to the Business characteristic level too. So do not be surprised to find Business terms as Borrower identification and Borrower name which are roles of Person identification and Person name.

In fact, roles at Business characteristic level occur more often than people sometimes realise. For example be aware that “Date” or perhaps better “Calendar date” may be the identification of the Business concept Calendar day. Dates are often used all around (Business) Data Models, in fact they are all roles of Calendar date.

Business Data Modelling - step 4: Model Business concept identifiers

Now that we have the Business characteristics assigned to the Business concepts, we should try to identify the Business concept identifiers per Business concept. Within traditional data modelling it is usually called a “key” which will have the role of storing and retrieving data from the accounting system. Because of this role, a key is not allowed to change, it would cause technical rearrangement of the data stored. Within Business Data Modelling, we only demand the uniqueness of the Business concept identifiers although we recognise that a change of data value of the Business concept identifier (of the Business object within the Business concept) is rare. For example, If we have the unique Data values 1, 2, 3, 4, and 5 for the different Business objects, the Data value 3 could change to 6. There would still be 5 different Business objects with unique values for the Business concept identifier.

Within Business Data Modelling we consider the uniqueness of (a group of) Business characteristics for a Business concept important. It actually is a Business rule that important, that it should be documented in a structured way within the meta data of the Business Data Model. It is hard to define a Business term which is a Business concept in such a way that you (from the definition) would exactly know which Business objects apply as a member of the Business concept and which not. It is text, and with the matters on subtypes and roles described above, it may remain insufficiently clear. Knowing the Business concept identifiers (there may be multiple) add significantly to the semantics of the Business concept.

For example, suppose you have modelled the Business concept Car, term owners and other business representatives agree so far. Within this step, some want chassis number as Business concept identifier and others the Car registration number which is on the vehicle number plate. Could there be two Business concept identifiers on the same Business concept? Or do some people discussing Car think of the physical thing parked outside while others focus on the registration of the car and include perhaps the characteristics of the physical car and the owner of the car? To help this discussion, one should question for example if there could be a physical car without a registration. There may be a yes for that question, the car is already there before it is registered. And when the car is disposed of, the registration may be taken from the physical car. Another relevant question is if the physical car could have multiple registrations. The answer may be that at one moment in time, a physical car can have only a single registration and a single registration is for a single physical car only. But over time, the same physical car may get a new registration (and a new number plate). This may be relevant for the Business and should be modelled. It can also be irrelevant for the Business to distinguish between the physical car and the registration because of their scope, also regarding the timeline of the car’s lifecycle that they monitor. Even in this last case, because we model the real business world, consider the physical car as something different from a registration (a car you can drive, a registration you cannot drive), create both Business terms and both Business concepts and create the Business concept relationship which may have the 1 to 1 cardinality within the context of the Business we model.

Please note that when modelling the real Business world, you may end up with Business characteristics and Business concept identifiers of which Data values are not allowed to be registered and stored in accounting systems. For example according to the GDPR guidelines valid since May 25th 2018 within the EU. Within The Netherlands, there are strict regulations on who may see or not see, store and not store the civil service number (BSN) of a Dutch Natural person. Within Business Data Modelling, because we model what is in the Business world and not what we store in accounting systems, we could still model these Business characteristics for the benefit of good semantics.

Business Data Modelling - step 5: Relationship modelling

In step 2 we already modelled the Business concepts by means of relating them to other Business concepts. These relationships are mostly already expressed in the definition of the Business terms. We called the relationships “Business concept relationship” and added Cardinality, Optionality and Duplicity (COD) for each side of the relationship. This last step (5. Relationship modelling) in Business Data Modelling supplies the option to add Business concept identifiers of one Business concept to the characteristics of another (or even sometimes: the same) Business concept, to enforce the Business concept relationship on Business characteristic level.

This technique is also used within traditional data modelling and the added characteristics are there often called a “foreign key”. Some people argue that adding them is not relevant for the meta model (a Business Data Model in our case) and that these characteristics even could be added automatically from the Business concept relationships already specified. Which would mean that they are redundant. The explanation below will show that this is not always the case and that (manual) relationship modelling on Business characteristic level will add information to the model. In fact, this information consists of Business logic which can be added in a structured way to the Business Data Model.

On our writing standard below: examples are given by:

  • Giving the name of the Business concept
  • Between brackets: listing the names of the Business characteristics
  • The first Business characteristic(s) listed is (are) the (primary) Business concept identifier and they are underlined.

Business characteristics can also be added to the diagram: the Business Data Model as long as this detailing serves a purpose and is not disturbing the overview of business concepts and their relationships.

The reference of which added identifiers relate to which Business concepts must be made clear to but will remain unmentioned here for the sake of making the examples not too complex at this stage.

As said, the basic principle is to add a Business concept identifier of one Business concept to the characteristics of another (or even sometimes: the same) Business concept to enforce a 1 to multiple Cardinality. More specific: the Business concept identifier at the 1-side of the relationship, will be added to the characteristics of the Business concept at the multiple-side of the Business concept relationship. There are 4 different ways of doing that, based on choices the Business made, resulting in 4 options:

Option 1: Extension of Business concept identifier.

For example we have Business concept Manufacturer with Business concept identifier Manufacturer code. A Manufacturer will produce multiple Articles. The Business concept identifier of Article could be the combination of Manufacturer code and (extension on top of the Business concept identifier of Manufacturer) Manufacturer article number. The construction is that any single Article (Business object within this Business concept) will hold a single Data value of the Manufacturer code and therefore the 1-side of the 1 to multiple Business concept relationship is enforced. From the other side, for any single Data value of Manufacturer code, multiple Articles can be defined holding the same Data value of Manufacturer code. This is possible because by using different Data values for the Manufacturer article number, the Business concept identifier of Article will remain to have unique (combined) Data values.

Manufacturer (Manufacturer code)

Article (Manufacturer code, Manufacturer article number)

Consequence: it must be common in Business that Manufacturers commonly agree on Manufacturer codes and that any Manufacturer will assign an unique range of Manufacturer article numbers and that it is unambiguously clear what Article with what specification is meant by the number. An other Manufacturer may use (by coincidence, some) identical Data values for the Manufacturer article number but together with the Manufacturer code, you will still have a unique Business concept identifier for Article.

Option 2: Addition as non-identifier characteristic.

For example we have Business concept Customer with Business concept identifier Order. And again a 1 to multiple Business concept relationship: a single Customer object can (in due time) place multiple Order objects. What we see here is that the Business chooses NOT to extend the Business concept identifier of Customer to create the Business concept identifier of Order. They use a sequence number (Order number) that is applied independently of the Customer (object) placing the Order object. The Business concept identifier of Customer will be added as a non-identifying characteristic of Order. The construction is that any single Order (Business object within this Business concept) will hold a single Data value of the Customer concept identifier and therefore the 1-side of the 1 to multiple Business concept relationship is enforced. From the other side, for any single Data value of the Customer concept identifier, multiple Order objects can have the same Data value of the Customer concept identifier. This is possible because they all have different Data values for the Order number.

Customer (Customer identifier)
Order (Order number, Customer identifier)
 

Consequence: there are no Business constraints in adding Order objects to a Customer object.

Option 3: Two birds with one stone.

We have discussed option 1: Extension of Business concept identifier and option 2: Addition as non-identifier characteristic. But suppose the Business concept identifier that must be added for reference, consists of multiple Business characteristics? Could it be possible that part of this identifier must be added to the Business concept identifier of the related Business concept and the remaining part of this identifier to the non-identifier characteristics of the other Business concept? In other words: could we have a combination of the options 1 and 2? The answer is YES and will be explained by means of the following example.

Suppose in financial accounting, you have General ledger accounts that have to be grouped and totalized into Balance accounts. It will probably be an option 2 relationship:

Balance account (Balance account name)
General ledger account (General ledger account number, Balance account name).

Suppose this company wishes to make different Balances according to different view points or standards. For example US GAAP and IAS. In that case, Balance as a Business term will definitely become a Business concept and can – together with Balance account – be represented as an option 1 relationship:
 

Balance (Balance name)
Balance account (Balance name, Balance account name).

In this situation, a Balance account will still be the aggregation of multiple General ledger accounts (objects), but new is that a General ledger account (object) may grouped and totalized into multiple Balance accounts. There is a business constraint here that we have to handle. Yes, a General ledger account (object) may be part of multiple Balance accounts but NOT of different Balance accounts within a single Balance. A General ledger account may be aggregated only once within a Balance. Because we have a Duplicity constraint here and also for the sake of explaining this aspect of relationship modelling, we split the multiple to multiple Business concept relationship between Balance account and General ledger account and create “Balance account detail”. To enforce the above mentioned Business rule we need to model the following relationship construct:
Balance (Balance name)
Balance account (Balance name, Balance account name)
Balance account detail (Balance name, General ledger account number, Balance account name).
General ledger account (General ledger account number, …).
 
Consequence: We have a multiple to multiple relationship between Balance Account and General ledger account, but with a limitation and that is: a General ledger account object can be aggregated into multiple Balance account objects but only if these Balance accounts objects are of different Balances (Balance objects). To enforce this Business rule, due to the Duplicity matter, we have split the multiple to multiple relationship into two 1 to multiple relationships..
Following the Business rule, we in fact model a multiple to multiple relationship between Balance (!) and General ledger account as an option 1 relationship, without the option of Duplicity. At the same time each Balance account detail (combination of “General ledger account within Balance”) is assigned to a single Balance account by adding the Balance account name as a Business characteristic to the Balance account detail. The Business concept relationship between Balance account and Balance account detail is an option 3 relationship. We call it Two birds with one stone because we add the identifier of Balance account to Balance account detail in a way that it enforces two Business concept relationships, to Balance and to Balance Account.

In short: there is a 1 to multiple relationship between Balance account and Balance account detail while the Business concept identifier of Balance account is partly added to the Business concept identifier of Balance account detail and the remaining part of this identifier is a non-identifier characteristic of Balance account detail. Therefore, this option 3 is a combination of an option 1 and an option 2 relationship construction in one.

Above we have explained three options in modelling relationships, based on what we called “the basic principle” that the Business concept identifier of one Business concept one way or another ends up at the related Business concept. For the 3 options, we have shown the relevance, the additional Business rules that can be enforced by relationship modelling.

Here we introduce option 4, we call it “inherited” because these type of relationships are the result of the existence of option 2 relationships. We might expect that we have already modelled the option 4 relationships in step 2 but actually they are often missed at that step. So it is good to be aware of option 4 “inheritance” Business concept relationships and next to document how to enforce them in relationship modelling. We first give an example and explain about this option 4.

Option 4: Inherited.

We start with the (probably most used) case on Customer, doing multiple Orders, consisting of multiple Order details. Order detail will hold the Business concept identifier of Article by which Article can be ordered by multiple Order details. For reasons of simplicity we assume that the Business needs an option 1 Business concept relationship between Article and Order detail (enforcing a single article to be placed to the Order just once).

So we have:

Customer (Customer identifier)

Order (Order number, Customer identifier)
Order detail (Order number, Article number)
Article (Article number, )

 

Suppose these Customers claim for example discounts on the regular price of an Article. So we have the Business concept Article claim related to the Article and Customer:

Customer (Customer identifier)
Article (Article number, )
Article claim (Article number, Customer identifier, Article claim discount percentage)

Now, Business explains that on any Order detail, the Article claim has to be applied in case there is one. So in fact, we have a Business concept relationship between Article claim and Order detail with a 1 to multiple Cardinality:
 

Article claim is applied to Order detail
Order detail is subject of Article claim

At the Order detail level we do have the Article number, but we lack the Customer identifier we need to enforce the Business concept relationship to Article claim. Fortunately, every single Order detail is related to a single Order and any single Order is related to a single Customer. So implicitly, any single Order detail is related to a single Customer. Within Business Data Management, we say that we inherited the single relationship to Customer from the Order level, to the Order detail level. So the Business concept relationship between Article claim and Order detail with a 1 to multiple Cardinality, is enforced by:
Article number at Order Detail

and
Customer identifier at Order.

In general we call this an option 4 relationship due to the absence of the full Business concept identifier on the lower level (at the multiple side) but which can be enforced by virtually inheriting parts of the Business concept identifier from related (higher level) Business concepts.

Analysis:
An option 4 relationship may only pop-up in case of an option 2 Business concept relationship. By choosing for Order number as Business concept identifier for Order, the Customer identifier is “left behind” at the Order level and is only by the principle of inheritance determinable at lower levels of the model. If it is Business custom to incorporate the Customer identifier as part of the Order identifier (option 1 relationship), the Customer identifier will be available on the Order detail level which will result in a more regular option 1 or option 3 business concept relationship between Article claim and Order detail.


A few remarks:

Do not make the mistake by adding the Customer identifier to the Order detail level. This will suggest that Order details of the same Order can be for different Customers. Do not “repair” modelling mistakes by adding Business rules to enforce the constraint. Constraints must be enforced within the model, within the relationship construction if possible.

In case not all Customers claim price reductions on all Articles, optionality must be modelled to show that for a Order detail the Article claim may be absent. This also means that the Business concept relationship between Article and Order detail is not redundant and should remain (not shown in the diagram above).

We said that for reasons of simplicity we assume that the Business needs an option 1 Business concept relationship between Article and Order detail. If they needed the Duplicity characteristic to have a single Article on multiple Order details of a single Order, we suggest to write out this case yourself and discover that it would still result into the option 4 relationship explained above.