Prácticas recomendadas para el modelo de datos

Declarar una clase de datos como abstracta en lugar de concreta era más importante en el pasado. Los nombres de las clases declaraban que las clases abstractas debían terminar con un guion. Ese requerimiento ya no existe.

Los términos “abstracto” y “concreto” se toman prestados del lenguaje de Java. Una clase abstracta es aquella que no puede ser heredada ni desarrollada. En Java, si intenta crear una clase abstracta con el nuevo() operador, obtendrá un error de compilación.

Un ejemplo de una clase abstracta, como se denomina en Pega, es la clase FSG-Data-Address de la aplicación de reservas. En Pega, puede crear una página FSG-Data-Location en el portapapeles usando Pega-New en una Actividad o con data transform simplemente configurando una propiedad en una página del paso FSG-Data-Location.

Hoy en día, la mayor distinción dentro de Pega entre “abstracto” y “concreto” reside en que el término “abstracto” hace referencia a que la clase de datos no define las claves. Una clase de datos que no define claves no puede almacenarse en una tabla de base de datos.

El esquema CustomerData más reciente eliminó el requerimiento de que una tabla de base de datos contenga columnas específicas de Pega. A diferencia de las tablas de los esquemas PegaData y PegaRules en donde pzInsKey debe ser la clave primaria, la tabla del esquema CustomerData nunca la usará como clave primaria. A partir de su versión 7.3, Pega incluye un cuadro de verificación en la regla Rule-Obj-Class. Cuando se selecciona, Pega usa pyGUID como clave principal y genera automáticamente un valor si el registro que se guarda aún no ha recibido un valor de pyGUID.

La información dentro de la clase de datos “concretos” está destinada a persistir fuera de un caso. Está permitido copiar datos concretos al caso para la captura de datos históricos. Cuando se realiza esta copia, la información histórica se integra en la columna pzPvStream de un caso, conocida como “BLOB”.  Los datos históricos también se pueden almacenar fuera de un caso BLOB. Cuando esto ocurre, agregar “-History” al final del nombre de la clase de datos ayuda a distinguir lo que representa la clase de datos. El almacenamiento de datos fuera del BLOB tiene beneficios desde el punto de vista de la herencia y la creación de reportes, no almacena datos dentro del BLOB ni tiene que definir una Declare Index para exponer los datos. La base de la clase Declare Index sería Index-, no Data-.

“Datos de referencia” es el nombre para un tipo especial de datos que, como su nombre lo indica, se conservan a modo de referencia. Los datos de referencia pueden usarse para propagar valores en una lista desplegable. En general, la clase de datos de referencia no tiene, o tiene muy poca, referencia a otras instancias de datos.

Desde la perspectiva del empaquetado, los datos de referencia se pueden considerar “atómicos”, “autónomos”, “encapsulados” o “sin salida”. La red de instancias de datos que se referencian entre sí se puede empaquetar como un todo y luego implementar en un entorno diferente, el cual se inicializa antes de ejecutar una aplicación.  Un ejemplo de una instancia de datos sin salida empaquetable en red es FSG-Data-Address que referencia a FSG-Data-Location, que, a su vez, hace referencia a FSG-Data-Contact. Una ubicación es información estática. Una ubicación puede crearse en cualquier momento antes de usarse. Varios casos BookEvent de la aplicación de reserva pueden hacer referencia a la misma instancia de FSG-Data-Venue. Esa instancia de lugar se almacena en la misma tabla del esquema de CustomerData que cualquier otra instancia de FSG-Data-Location.

Un instancia de datos de referencia completa no debería copiarse ni persistir dentro de un BLOB de caso a menos que sea un requerimiento. Una razón para copiar los datos es que los valores son transitorios (por ejemplo, el precio). A lo largo del tiempo, el precio de un producto puede cambiar. Se puede hacer una copia de la instancia de datos completa por razones de auditoría histórica.

Si se realiza una copia de los datos históricos, también es importante conservar los valores de búsqueda que se usaron para recuperar los datos (es decir, el motivo por el que se accedió a esos datos en particular). Por ejemplo, cuando se conserva el registro FSG-Data-Pricing, no solo se registra la información de ItemID, Reference y Price, sino que también se registran entradas como Quantity, Bit y Discount Factor. De este modo, el mismo precio histórico se puede volver a derivar en el futuro con esas entradas. Si en el futuro, se agrega una columna de AsOfDate a FSG-Data-Price, FSG-Data-Pricing debe registrar el valor de la fecha que se usa cuando se consulta FSG-Data-Price.  Copiar un precio histórico es beneficioso por motivos de rendimiento, ya que hacerlo evita tener que realizar los mismos cálculos que se usaron para calcular su valor cuando se almacenó el precio originalmente. Imagine una factura con varios elementos de línea. 

Si no se realizan cálculos, tiene sentido hacer una búsqueda (patrón SOR) o JOIN desde el caso a los datos de referencia en lugar de incrustarlo (patrón de Snapshot) en el BLOB del caso. Un ejemplo son los nombres de almacenamiento. Los nombres pueden cambiar con el tiempo. Pega no tiene control sobre ello. Sin embargo, Pega sí tiene control sobre un Id. único generado. No debe usarse un nombre como clave. Si realiza una consulta basada en un nombre, no asuma que se recuperará una sola fila.

Un ejemplo de una clase abstracta es la clase de ruleset de componente, FSG-Data-Hotel-RoomsRequest, que comparten las aplicaciones Hotel y HotelProxy. Tenga presente que FSG-Data-Hotel es una clase de datos concretos de referencia definida a nivel empresarial. Cuando usa el asistente de tipo de datos para definir un nuevo tipo de datos, es posible seleccionar uno que ya existe, incluida una clase concreta. El asistente de tipo de datos agrega el nombre que ingrese, por ejemplo, “RoomsRequest” al nombre de la clase existente, por ejemplo, “FSG-Data-Hotel”, usando un guion (“-”) como separador. Se crea un nombre de clase heredada de patrones.

FSG-Data-Hotel-RoomsRequest nunca se conserva porque se usa exclusivamente para la integración entre las aplicaciones de Hotel y HotelProxy. Almacenar una instancia de datos en las bases de datos de las aplicaciones no beneficia a la aplicación HotelProxy ni viceversa.   

Otro ejemplo en el que los datos se encuentran estrechamente acoplados al caso (y por lo tanto son incrustables) ocurre cuando la clase de datos es prácticamente un sinónimo del caso en sí. El objetivo de la clase de datos es asistir al caso en el desempeño de su rol como sistema de registros (SOR) para una transacción. La clase de datos cumple su función proporcionando la posibilidad de reusar ciertas reglas, como las secciones, las vistas y los data transforms. Varios tipos de caso pueden usar las mismas clases de datos del mismo modo (por ejemplo, como una clase abstracta).

Esos tipos de caso no necesitan hacer referencia a una instancia concreta de esa clase de datos. La clase de datos minimiza la cantidad de propiedades a nivel del caso que se crearon. Cuanto mayor sea el número de propiedades escalares que tenga un caso, más difícil será mantener el caso (por ejemplo, ¿para qué se usa la propiedad escalar X? ¿Para qué se usa la propiedad escalar Y?).

Cuando varios tipos de casos incluyen el mismo grupo de campos o la misma propiedad de lista de grupos de campos, resulta atractivo mover esa propiedad a la clase de grupo de trabajo. Si el análisis del modelo de datos se realiza correctamente, nunca se llegará a este punto. El hecho de que varios tipos de casos usen el mismo grupo de campos o propiedad de lista de grupo campo es un indicador de que es posible que la propiedad también sea útil para aplicaciones del mismo nivel.  Se recomienda adoptar la práctica de definir la propiedad dentro de la aplicación incorporada. Se perdió la posibilidad de descomponer la aplicación actual en aplicaciones del mismo nivel integradas a una aplicación incorporada compartida.

Los participantes necesitan una manera de “participar” en el concurso con un torneo.  Sin embargo, se presentaría un problema de concurrencia. Solo un concursante podría actualizar un caso de concurso a la vez si se le permitiera a un concursante acceder directamente a un caso del concurso. Además de hacer que la aplicación de la seguridad sea más compleja, se genera una User Experience (UX) deficiente, ya que se indica al cliente que el caso está bloqueado y debe intentarlo de nuevo más tarde.

Los concursantes podrían, en cambio, hacer sus selecciones dentro de una instancia org-data-contestant-contest. La parte -Contest de la clase sería similar a una clase Link-. Una propiedad ContestRef apuntaría al caso Contest. Una segunda propiedad, ContestantRef, apuntaría al concursante. De acuerdo con la Ley de Deméter, sin embargo, esto no es incorrecto. 

La Ley de Deméter dice que se deben evitar las rutas redundantes al mismo objeto. Si el caso del torneo eliminara un concurso, las instancias de Contestant-Contest seguirían apuntando al concurso eliminado, a pesar de que el concurso ya no esté asociado al torneo.

Este escenario implica que un caso de torneo debe proporcionar una “API” para que los concursantes sepan qué concursos están activos.

Una consulta busca lo siguiente:

1. Instancias de Contestant-Tournament que hacen referencia tanto al concursante como al caso del torneo.
2. Instancias de concurso en las que pxCoverInsKey es igual al pzInsKey del caso de torneo.

Una práctica recomendada es definir cada clase de datos que sea central para el modo en el que una organización hace negocios en la capa empresarial.  Imagine que una clase de datos es central para una organización. En ese caso, es posible que una aplicación en el mismo nivel se desarrolle para usarse en la misma clase. No tiene sentido forzar dos aplicaciones de Pega dentro de la misma organización para compartir información mediante la integración y los data transform. La clase de datos debe ser la misma. Esto no es diferente a esperar a que todas las aplicaciones usen clases de datos de Pega como Data-Party. 

Si una aplicación tiene propiedades adicionales que quiera agregar a una clase de datos de nivel empresarial (propiedades que no se apliquen a otras aplicaciones), la aplicación puede heredar directamente la clase de datos de nivel empresarial y luego agregar esas propiedades. De acuerdo con el principio de abierto y cerrado, cualquier cosa que funcione en el nivel empresarial debería funcionar igualmente en el nivel de la aplicación desde la perspectiva de la aplicación empresarial. No es importante para la aplicación empresarial qué ocurrió puntualmente en el nivel de la aplicación, solo es relevante que la funcionalidad “X” se haya ejecutado. 

Ocasionalmente, las aplicaciones definen clases de datos específicas para esa aplicación y no heredan una clase de datos que no sea de Pega que se define en la capa de reutilización; esto ocurre cuando ninguna otra aplicación necesita usar la misma clase de datos.

Es común para el caso capturar su carga útil principal (los datos que el caso administra) dentro de una estructura de datos que sea un sinónimo de esa clase. Si es posible que el nombre de un caso sea un sustantivo, en general, nombre al caso acción + sustantivo o sustantivo + acción, por ejemplo BookEvent. Este estilo se aplica porque es posible que el mismo sustantivo, en este caso “Event”, sea procesado por varios tipos de caso. Por ejemplo, EventBilling puede ser un segundo tipo de caso que opere contra los datos de “Event”. 

No es necesario agregar Details (Detalles) o Information (Información) al sustantivo que un caso administra. El sustantivo es un modelo de lo que es un objeto, su propósito es encapsular detalles o información sobre un objeto del mundo real. No es necesario que repita esta acción con el nombre de la clase. Evite la redundancia.

Repetir el nombre de clase del propietario de una propiedad dentro de su propio nombre es redundante y poco práctico. Por ejemplo, no debe llamar a una propiedad de la clase de datos FSG-Data-Event EventStartDate. Se entiende que la propiedad está relacionada a un evento. Nombre a la propiedad StartDate.

Del mismo modo, el caso BookEvent no necesita una propiedad de grupo de campos FSG-Data-Event llamada EventDetails. Event es suficiente, no es necesario agregar Details.

Por último, no nombre la clase de datos para ese grupo de campos de Event FSG-Data-EventDetails. La palabra “Details” no agrega ningún valor. Por el contrario, Details hace que el modelo de datos sea más difícil de comprender. Agregar Details sugiere que ese término está allí por alguna razón. ¿Hay alguna otra clase de Event que no contiene detalles? Nombre a la clase de datos FSG-Data-Event. 

La integridad de datos consiste en mantener una fuente única de verdad, es decir, la práctica de almacenar los mismos datos en una sola ubicación y no en dos diferentes. Este principio es la razón detrás de las técnicas de normalización de bases de datos; lo más importante: “para liberar la colección de relaciones de dependencias de inserción, actualización y eliminación no deseadas” (Edgar F. Codd, 1970). Imagine que los mismos datos, o un derivado de ellos (como la categoría de puntuación del promotor), se almacenan en varios lugares. ¿Qué sucede si los datos originales cambian?  La dificultad y la complejidad del mantenimiento aumentan si se espera que una aplicación realice un seguimiento y actualice cada ubicación donde se almacena el mismo valor cada vez que este cambia. Imagine que un Rule-Declare-Trigger tiene que lidiar con varias instancias bloqueadas de forma simultánea. 

Consulte el siguiente enlace para obtener información adicional sobre el modelo de datos: Seminario web sobre la excelencia de datos (Data Excellence Webinar).