Lineamientos orientados al diseño y el rendimiento

<< Clic para mostrar Tabla de Contenidos >>

Navegación:  Bizagi Studio > Mejores prácticas y recomendaciones de implementación > Mejores prácticas en el Modelo de Datos >

Lineamientos orientados al diseño y el rendimiento

Introducción

La siguiente sección lista los lineamientos que le ayudarán a diseñar su modelo de datos.

Tales lineamientos deben ser considerados desde las etapas tempranas de su proyecto, para lograr un modelo de datos eficiente (que promueva buen un rendimiento y usabilidad).

Tenga presente que es muy importante que las etapas tempranas de análisis y diseño se ejecuten de manera apropiada, y así lograr que por medio de un buen análisis y diseño se ahorre tiempo durante la implementación de sus procesos y evitar tener que rehacer y volver diseñar la implementación.

 

Lograr modelos de datos eficientes

En el diseño del modelo de datos de sus procesos de Bizagi y sus proyectos en general, dedique una cantidad adecuada de tiempo para el análisis, e involucre a los miembros y stakeholders relevantes.

La definición adecuada de la estructura del modelo de datos del proceso, es un punto crítico en los procesos de automatización por estas razones:

Afecta notablemente la dificultad de acceder a la información del modelo de datos desde formas y expresiones.

Determina la capacidad de comunicar con claridad el modelo de datos con los miembros del equipo y los dueños de proceso.

Determina cómo se consulta la información.

Determina la capacidad de reutilizar información.

Determina la capacidad de administrar la información.

Determina cómo se actualizará la información.

 

 

1. Lineamientos de diseño

A continuación encontrará lineamientos de mejores prácticas donde se siguen principios conocidos para un buen diseño del modelo de datos.

 

1.1. Defina el modelo de datos promoviendo el diseño orientado a objetos

Con esta premisa, es posible que también desee revisar si su modelo de datos ofrece los medios adecuados para utilizar la navegación XPath en sus otros elementos de proceso (por ejemplo, en las formas y reglas de negocio).

 

El siguiente ejemplo es una parte del Modelo de Datos del Proceso de Solicitud de Préstamo. Observe que en la izquierda cuán largo es el XPath que se utiliza para acceder desde la entidad de aplicación, al nombre de la referencia del Solicitante (Applicant Reference) y lo corta que es en el lado derecho con sólo cambiar la relación entre las entidades.

 

En este caso, una captura errónea de la lógica de negocio dificultará las búsquedas de información en formas, expresiones e interfaces.

 

BPDatamodel8

 

1.2. Evite conectar todas las entidades entre sí

El Modelo de datos de Bizagi está diseñado para utilizar XPath de una manera lineal (un solo sentido). No debe construir el modelo de datos de Bizagi conectando todas las entidades entre sí.

 

En la siguiente imagen, verá que hay una entidad de proceso: Travel Request. Ese es el punto de partida de la navegación, por lo tanto, la navegación será lineal en oposición a una situación en la que todas las entidades están conectadas entre sí.

 

BPDatamodel5

 

1.3. Use atributos de Scope cuando aplique

Evite incluir información que se utilice de forma temporal en actividades o procesos y que no agreguen valor al modelo de datos. Puede utilizar Atributos de Scope para mantener el Modelo de Datos claro.

 

BPDatamodel1

 

1.4. Utilice adecuadamente las entidades maestras y paramétricas

Tenga presente que Bizagi tiene un manejo diferente para los 2 tipos de entidades (p.e en el manejo de información y heurísticas de optimización), y que también existen algunas funcionalidades que solo aplican a cada tipo de entidad.

Por ejemplo, las entidades Maestras son consideradas como datos de negocio (no se despliegan sus valores desde el ambiente de desarrollo a producción), mientras que las entidades Paramétricas pueden definirse como metadata (lo contrario).

Dentro de las características que pueden ser utilizadas únicamente por entidades Paramétricas, usted tiene la posibilidad de definir entidades padres, y así usar el combo en cascada en las interfaces de usuario.

 

Tenga en cuenta los diferentes escenarios de negocio en su proceso para saber cuándo una entidad debe ser Paramétrica o Maestra. Para esto no hay una solución única. Las siguientes preguntas pueden ser útiles para determinar qué tipo de entidad usar:

 

¿La información se puede acceder y modificar desde diferentes procesos? Utilice una entidad Maestra.

¿La información es parametrizable? Utilice una entidad Paramétrica.

¿Se necesita sincronizar información de Bizagi en una fuente externa y viceversa (virtualización)? Utilice una entidad Maestra.

¿Se necesita importar y actualizar información en Bizagi, que proviene de una fuente externa y no cambia con tanta frecuencia (replicación)? Utilice una entidad Paramétrica.

 

1.5. Use la Virtualización o Replicación de datos cuando aplique.

Recuerde que tanto la Virtualización como la Replicación de datos son tecnologías excelentes para la reutilización de información almacenada en fuentes externas.

Si la información que necesita en su proceso ya existe en una fuente externa y tiene acceso a ella, utilice las funciones de Virtualización y Replicación.

 

 

1.6. Defina qué información puede ser modificada en ambientes de producción

Parte de la información puede requerir ser editad< por los usuarios finales en ambientes de producción debido a las condiciones cambiantes del negocio. Asegúrese de llevar a cabo un profundo análisis para determinar qué información puede ser modificada en ambientes de producción, con el fin de evitar los despliegues frecuentes para adaptar la información a las condiciones de negocio actuales.

 

Utilice la opción Administrar valores en producción exclusivamente que se encuentra en las propiedades de las entidades paramétricas para definir si la información se puede editar en el ambiente de producción o exclusivamente en el de desarrollo.

 

BPDatamodel3

 

 

2. Lineamientos de rendimiento

Construir un modelo de datos siempre con criterios de rendimiento en mente es un aspecto importante en las etapas tempranas de su proyecto.

La forma en que se define un modelo de datos afecta al rendimiento de la aplicación y la experiencia del usuario. Una definición adecuada del modelo de datos mejorará la experiencia del usuario y permitirá una escalabilidad de la solución más sencilla.

Considere estos lineamientos para evitar potenciales incidentes relacionados al rendimiento de su aplicación.

 

note_pin

Nótese que para un rendimiento óptimo, usted también debe considerar cómo define las formas (interfaces de usuario).

Contemplar qué acciones o cuándo se ejecutan, tanto del lado del cliente o del servidor, y qué información se presenta (y se refresca) al usuario final, es fundamental para definir sus formas orientadas a un buen desempeño.

 

 

2.1. Utilice un tamaño adecuado para los atributos de tipo texto

Algunos proyectos tienden a crear atributos largos de tipo String (con más de 250 caracteres) para todos los atributos de texto, sin tener en cuenta para qué van a ser utilizados.

 

Es importante que utilice un tamaño adecuado para los atributos de texto de acuerdo con lo que van a almacenar. (es decir, no crear una cadena de 500 caracteres para un atributo de texto que almacenará los números de teléfono). Como una buena práctica orientada al rendimiento de la base de datos, los atributos de tipo String deben reservar sólo la longitud necesaria.

 

BPDatamodel6

 

2.2. Cree entidades con 30 atributos o menos

Al definir una Entidad, evite crear un gran número de atributos, ya que esto exigir más recursos al ejecutar consultas que involucren la Entidad. Tener un gran número de atributos (más de 30) en una sola entidad puede dar lugar a problemas de rendimiento.

 

Es común suponer que un conjunto de atributos pertenecen a una gran entidad única, pero le animamos a que considere dividir las entidades más grandes en entidades relacionales más pequeñas cuando sea posible.

 

Es común que este tipo de entidades en un principio parezcan necesitar muchos atributos, por favor considere relaciones adicionales para descomponer la forma en que la información se distribuye de una manera más adecuada.

 

Supongamos que tenemos el proceso Evaluación de Préstamo con un proceso entidad: Loan Application.

Guardamos todos nuestros atributos relacionados con la evaluación de la aplicación en esa entidad. Pero luego, nos dimos cuenta de cómo crecía, y supimos que tenía que se debía romper para evitar problemas de rendimiento.

Por ello, hemos creado una nueva entidad llamada Solicitante (Applicant), donde colocamos toda la información relacionada con la persona que solicita el préstamo para reducir el número de atributos en la entidad de proceso. En la siguiente imagen, se observa cómo una entidad muy grande se puede dividir en dos. Podríamos haber roto en más entidades relacionadas, si fuera necesario.

 

BPDatamodel7

 

2.3. Defina llaves de negocio para las entidades y promueva su uso en la búsqueda de los registros

Como una buena práctica general para mejorar el rendimiento de las consultas y búsquedas, defina una llave de negocio.

Una vez definida la llave de negocio para sus entidades, asegúrese de que las búsquedas se realizan a través de esta opción para promoverla (por ejemplo, un control de búsqueda que tiene una columna que se asocia con la llave de negocio dada).

 

En el siguiente ejemplo hemos definido el número de documento (Document Number) como la clave de negocio para la entidad Cliente en lugar de utilizar el id de la entidad.

 

BPDatamodel4

 

note_pin

Cuando se han definido llaves de negocio en una entidad, asegúrese de utilizar la opción de valores por defecto de manera inteligente.

A través de los valores de defecto en un control, usted asignará un valor inicial para un atributo específico de la entidad (diferente a los de la definición de la llave de negocio) en un nuevo registro.

Si después selecciona y asocia otro registro, entonces usted no habrá asegurado que el nuevo registro con la información inicial tenga un valor no nulo en la llave de negocio.

Por lo tanto, se recomienda que no use valores por defecto si usted planea asociar esa información a un registro existente.