Overview
The following section lists guidelines that will help you in your Data model design.
Such guidelines should be considered in early stages of your project for an efficient Data model (and achieve expected performance and usability).
Recall that it is very important that analysis and design stages are executed appropriately, as this will most likely save time during the implementation of processes and avoid having to go back to rethink and undo already implemented objects.
Modeling efficient Data models
When designing the Data model of your Bizagi Processes and projects in general, dedicate an adequate amount of time for analysis and involve the relevant team and Personas.
This can't be stressed enough since adequately defining the structure of a Process Data model is a critical point in Processes automation for these reasons:
•Notably affects the difficulty of accessing the information of the Data model from Forms and expressions.
•Determines the capacity to clearly communicate the data model to team members and Process owners.
•Determines how the information is consulted.
•Determines the capacity of reusing information.
•Determines the capacity of administrate the information.
•Determines how the information is updated.
1. Design guidelines
Below you will find guidelines to follow best practices' principles which aid in the Data model definition.
1.1. Define the data model promoting objected-oriented design
With this premise, you may also want to review if your data model offers adequate means to use XPath navigation in your other Process elements (e.g. in forms and business rules).
The example below is part of the Data Model of a Loan Application Process. Look at the left how long is the XPath used to access the name of the Applicant Reference from the Application entity and how short is it on the right side just by changing the relationship between entities.
In this case a wrong capture of the business logic will difficult searches for information in Forms, expressions and interfaces.
1.2. Avoid connecting all entities with each other
Bizagi's Data model is designed to use XPath, in a linear way (a one-way only). You should not model Bizagi's Data model connecting all entities with each other.
In the image below you will see that there is a Process entity: Travel Request. That is the starting point of navigation. Thus, the navigation will be linear as opposed to a situation where all entities are connected with each other.
1.3. Use scope attributes when applicable
Avoid including information that is used temporary in activities or processes and that add no value to the Data model.
You can use Scope attributes instead and keep the Data model clear.
1.4. Use Master and Parameter entities adequately
Recall that Bizagi has a separate treatment for its entity types (i.e optimization heuristics and information management), and also has a small set of features that only apply for each of the 2 types.
Master entity types are for instance considered data (their values not deployed from a development to a production environment), while Parameter entity types you may choose to define them as metadata (the opposite).
Among the features which can be used only by Parameter entities, you have the possibility to define parent entities to use Cascading combos in the user interfaces.
Consider the different business scenarios in your Process to conclude when an Entity should be of the Parameter type or the Master type.
There is no unique solution for this subject. The following questions may be useful to determine which type of entity use:
•The information can be accessed and modified from different Processes? Use a Master entity
•The information is preset as an administration task? Use a Parameter entity
•Synchronizing information both from Bizagi into an external source and vice versa, is needed (Virtualization)? Use a Master entity
•Importing and updating information in Bizagi, which comes from an external source and does not change as frequently, is needed (Replication)? Use a parameter entity
1.5. Use Data Virtualization or Data Replication when applicable
Recall that Data Virtualization and Data Replication is an excellent technology to reuse information stored at external sources.
If the information you need in your Process already exists in an external source and you have access to it use the Data Virtualization and Data Replication features.
1.6. Define which information should be managed in the Production environment
Some information may require to be edited by end users in production environments due the changing business conditions. Make sure you perform a deep analysis to determine which information can be modified in Production environments in order to avoid frequent deployments to adapt the information to the current business conditions.
Use the option Manage values in production environment only found in the Parameter entities properties to define if the information can be edited in production environment or exclusively in development.
2. Performance guidelines
Building the Data model thinking on Performance is an important aspect in the early stages of your project.
The way a Data model is defined also affects the performance of the application and user experience. An adequate definition of the Data model will enhance the user experience, and allows a simpler scalability of the solution.
Consider these guidelines to avoid performance issues.
|
Note that for an optimal performance, you will also need to consider how you define your forms (UI). What actions or triggers are executed both at the client and server side, what information is presented (and refreshed) to the end users are fundamental to define your forms avoiding performance issues. |
2.1. Use an adequate size for text attributes
Some projects tend to create several long-string attributes (with over 250 characters) for all text attributes disregarding what they will be used for.
It is important that you use an adequate size for text attributes according to what they will store. (i.e. do not create a 500 character string for a text attribute that will store phone numbers). As a good practice oriented towards Database performance, String attributes should reserve only the length needed.
2.2. Create entities with 30 attributes or less
When defining an Entity, avoid creating a large number of attributes as this will demand more resources when executing queries involving that Entity. Having a large number of attributes(more than 30) in a single entity may result in performance issues.
It is common to assume that a set of attributes belong to one large single entity, but we encourage you to consider breaking larger entities into smaller relational entities when possible.
It is common that such Entities that would initially seem to need a lot of attributes, please consider additional relationships to break down how the information is distributed in a more appropriate way.
Suppose we have a Loan Assessment process with a process entity: Loan Application.
We saved all our attributes related to the assessment of the Application in that entity. But then we noticed how it grew, and realized that it had to be broken to avoid performance issues.
So we created a new entity called Applicant, where we placed all the information related to the person who requested the Loan to reduce the number of attributes in the Process entity. In the image below you will notices how a very large entity can be broken in two. We could have broken it into more related entities if needed to.
2.3. Define business keys for Entities and promote their use when searching for records
To improve the performance of queries and searches define business key as a general good practice (these may be seen as indexes).
Once you define a business key for your entities, make sure that searches are done through this option to promote it (i.e, a search control having the column which is associated with the given business key).
In the example below we defined the Document Number as the business key for the Customer entity instead of using the entity id.
Business keys promote additional advantages related to data integrity, and related to integration and security:
•When creating a new record, you avoid duplicates by having Bizagi automatically validate that a record with the same business key value does not already exist.
•When integrating with other systems, you rely on unique codes for certainty that both Bizagi and the external system are referring to a same record.
•When integrating with other systems, information you exchange with, and send over to other systems, would be in codes.
This is compliant to some industry-specific standards such as HIPAA, and it allows you to not send intuitive or easy-to-read business sensitive information, in case such information is intercepted by unauthorized parties.
|
When having defined a business key in an entity, make sure you use default values wisely. Through the default value of a control, you will assign an initial value for a specific attribute of that entity (other than the attributes making up the business key) in a new record. If you then select and bind the case to another record, you will not have guaranteed that the new record with that initial value has a business key that is not null. Therefore, it is recommended to make sure you don't use default values if you are planning to bind that information to an existing record. |
2.4 State log as Entities
You can configure which entities require a log in the Bizagi Studio Wizard with the State log by Entities. This is a log that shows the entities that have been modified during a Process. When you enter the Details link in the log, you can see for each modified attribute: its display name, the final value, the name of the Activity where the attribute was modified, the name and the position of the user who modified the attribute and the Modification Date.
You can also filter the information by attribute or by user.
To use a filter, enter the entity’s Advanced Properties. To do so, right click on the entity and click on Advanced Properties.
It is recommended that logging is only activated for entities that need to be tracked for business needs, given that this could affect the database size.
|
Bear in mind that the log is deactivated by default. When you create an entity the log must be activated if you need it. |
Last Updated 1/6/2022 11:15:56 AM