Modelado de datos Greenfield
Tipos de modelado de datos
Hay dos tipos de modelado de datos en Pega:
- Modelado de datos Greenfield
- Ampliar el modelo de datos existente
El modelado de datos Greenfield es el nombre que se asigna a la situación de crear un modelo de datos desde cero. El modelado de datos Greenfield es obligatorio cuando el modelo de Pega, del socio o de Marketplace no representa el modelo de datos del cliente (o el cliente tiene un modelo con licencia). Una técnica para desarrollar un modelo de objeto es analizar el documento y extraer sustantivos y verbos. Los sustantivos se toman como tipos de datos y los verbos como procesos. Los procesos pueden ser un tipo de caso o una acción que sucede dentro de un tipo de caso. Una vez identificados los sustantivos, comienza el trabajo de modelado de datos.
Las técnicas de modelado de datos estándar de la industria se enfocan primero en las necesidades de datos del negocio o la aplicación, y remiten todas las consideraciones físicas del modelo de datos hasta el cumplimiento de las necesidades del negocio y la aplicación.
El modelado de datos sigue un enfoque de tres niveles.
- Conceptual
- Lógico
- Físico
Como Lead System Architect (LSA), desempeña un rol importante en cada nivel de modelado de datos al colaborar con otras partes interesadas. En la siguiente tabla, se muestra qué acciones se realizan en qué nivel.
| Nivel de diseño | Partes interesadas | Acciones |
|---|---|---|
| Conceptual | Negocio/Cliente/SME para el dominio empresarial | Identificación del origen de datos; Comprensión del flujo de información; Elección del tipo de datos correcto para los elementos de datos |
| Lógico | Analista de datos del negocio/Experto en datos | Diseño y decisión de la recopilación de datos; Elección de la capa correcta para los elemento; Grupo de elementos lógicos mediante la herencia o composición |
| Físico | DBA/Desarrollador/SME del cliente para SOR | Elección del esquema correcto y creación de la tabla de base de datos |
Nivel de concepto en el modelado de datos
En este nivel, las partes interesadas principales son el negocio, el cliente y el Subject Matter Expert (SME). El propósito es definir las condiciones y reglas de negocio. Identificar los datos y cómo fluyen en el proceso. El resultado del nivel de concepto es una comprensión clara de los datos (y el tipo de datos) necesarios para satisfacer las necesidades del negocio.
Nivel de lógica en el modelado de datos
En este nivel, las partes interesadas principales son los analistas de datos del negocio y los expertos en arquitectura de datos. El rol del analista de datos del negocio es explicar cómo y de dónde se recopilan los datos. El rol proporciona las capacidades de decisión para la recopilación de datos y el diseño lógico en el contexto de las necesidades del negocio, las condiciones y políticas. El rol del experto en arquitectura de datos identifica la relación entre los tipos de datos (claves definidas), la capa de reutilización en la que ubicar los tipos de datos (capa de organización o capa específica), la ruta de herencia para los datos.
Nivel de aspecto físico en el modelado de datos
En este nivel, las partes interesadas principales son los administradores de bases de datos (DBA), los desarrolladores y otros arquitectos del cliente que son expertos en la materia (SME) de SOR. El DBA creará la tabla de base de datos física según la orientación del desarrollador o SME. Es un trabajo colaborativo. El propósito es finalizar la metodología de implementación para los elementos de datos. El diseño lógico toma una forma física en este nivel.
Cree las clases de datos necesarias en Pega para asignar las tablas de base de datos de Pega o las tablas de base de datos externas. De ser necesario, cree el conector para acceder a los datos de los sistemas externos. Como un LSA específico de Pega, también debe elegir los esquemas apropiados para el requerimiento del negocio. El plan debe ingresar en CustomerData y DATA de Pega. Analice la necesidad de usar la base de datos de reportes de Pega también en este nivel.
En este nivel se realiza el formateo, los cálculos y el manejo de datos para que tener listos todos los datos necesarios para el proceso de negocio.
Polimorfismo en el modelado de datos
En Pega, puede modelar estructuras de datos avanzadas y dinámicas mediante el tipo de campo de Data Relationship (Relación de datos). El modelo de datos de Pega es poderoso y flexible y admite conceptos como el polimorfismo. Declare un tipo de campo de relación de datos que se asigna a una clase abstracta en el momento del diseño y de la ejecución; pxObjClass del campo se actualizará con el nombre de clase específico requerido.
Considere el siguiente escenario de negocio:
Una aplicación de la empresa de seguros tiene una lista de vehículos que asegurar como parte de un pedido. La lista de vehículos puede incluir autos, motos y camiones. Cada uno de estos tipos de vehículos tienen diferencias en sus procesos y reglas de negocio. Los siguientes modelos de datos son posibles soluciones para este problema de negocios.
Solución 1: separar el tipo de campo (de varios registros) Data Relationship (Relación de datos) para cada tipo de vehículo
Cree un tipo de campo Data Relationship (Relación de datos) con varios registros con listas para Autos, Motos y Camiones. Cada lista de tipo de campo de Data Relationship (Relación de datos) tiene una clase de página estática. Los desarrolladores pueden tener que crear interfaces de usuario separadas para cada clase de página.
| Nombre del campo embebido | Corresponde a la clase | Comentarios | |
|---|---|---|---|
| Lista de autos | Data-Vehicle-Car | Clase diferente definida para cada tipo de vehículo | |
| Lista de camiones | Data-Vehicle-Truck |
|
|
| Lista de otros vehículos | Data-Vehicle-Other |
|
Solución 2: tipo de campo Data Relationship (Relación de datos) único (con varios registros) y clase de página única para todos los tipos de vehículos
Otra opción es usar solo una clase de una página para todos los vehículos y un único tipo de campo (con varios registros) Data Relationship (Relación de datos). En este caso, debe usar la lógica condicional o debe hacer una puesta en circunstancia para presentar el proceso y las diferencias de regla.
| Nombre del campo embebido | Corresponde a la clase | Comentarios |
|---|---|---|
| Lista de vehículos | Data-Vehicle | Solo una página embebida y se usa la lógica condicional para identificar los UI y otras reglas necesarias en función del tipo de vehículo. |
Solución 3: tipo de campo Data Relationship (Relación de datos) único (con varios registros) y clase de página diferente para diferentes tipos de vehículos
Puede usar un tipo de campo Data Relationship (Relación de datos) único (con varios registros) de los vehículos incluidos donde cada página puede ser un tipo de clase diferente. La resolución de reglas usa una clase de tiempo de ejecución de cada página para aplicar las reglas, los procesos y la interfaz de usuario correctos.
| Nombre del campo embebido | Corresponde a la clase | Comentarios |
|---|---|---|
| Lista de vehículos | Data-Vehicle | La lista de vehículos está asignada a la clase Data-Vehicle y cada página puede tener una clase asignada según el tiempo de ejecución |
| Bicicleta | Data-Vehicle-Bike | La primera página de la lista de vehículos es Bicicleta |
| Auto | Data-Vehicle-Car | La segunda página de la lista de vehículos es Auto |
| Camión | Data-Vehicle-Truck | La tercera página de la lista de vehículos es Camión |
Recomendación:
- Se recomienda la solución 3. Puede agregar con facilidad un nuevo tipo de vehículo y asignar la página en la lista de vehículos a la nueva clase de vehículo.
- La solución 1 no se recomienda porque no es escalable. Por ejemplo, ¿qué sucede cuando se agrega un nuevo tipo de vehículo, como Botes? Tener varias listas de página puede requerir la modificación de varias reglas para implementar este cambio.
- La solución 2 no se recomienda. Con una clase de lista de página única, las reglas de negocio son más difíciles de mantener y hay muchas más circunstancias y variantes de la lógica del negocio.
This Topic is available in the following Module:
¿Quiere ayudarnos a mejorar este contenido?