Skip to main content

Diseño del modelo de datos

  

Un modelo de datos bien diseñado tiene el beneficio de la reutilización, en gran medida lograda mediante la especialización, y el mantenimiento simple. El diseño del modelo de datos es tan importante como el diseño del proceso para un proyecto de software.

El modelo de datos ofrece un buen proyecto del flujo de datos completo en el ciclo de vida de los procesos de negocio. Un buen proyecto de los datos ayuda a utilizar los datos con eficiencia y perfección.

Cuando comienza a diseñar la solución de modelo de datos para el escenario de negocio dado, los pasos básicos del modelado de datos son estos:

  • Identificar objetos de datos.
  • Identificar atributos para cada objeto de datos.
  • Identificar objetos de datos existentes que se pueden reutilizar (herencia o composición).
  • Relacionar los objetos de datos.
  • Planificar para lograr persistencia/integración de los objetos de datos creados por la aplicación.

El diseño del modelo de datos es muy importante y una fase clave en el desarrollo de la aplicación a fin de cumplir las necesidades del negocio. Un Lead System Architect (LSA) se centra en el modelado de datos para aprovechar los siguientes beneficios.

  • La complejidad de los datos se puede reducir mediante la clasificación y el modelado de datos.
  • Con el modelado de datos, se pueden identificar los datos requeridos para cumplir los requerimientos del negocio. Se pueden hacer planes para capturar los datos desde el origen y evitar cualquier pérdida de datos.
  • El modelado de datos ayuda en el diseño de un plan de guardado de datos para que todos los datos obtenidos se conserven y se mantenga la integridad del sistema.
  • La precisión y exactitud de los datos se pueden mantener teniendo en cuenta los diseños de integridad de datos (manteniendo una fuente de verdad única).
  • En el modelado de datos se puede planear el proceso de resguardar y publicar los datos para otras partes.
  • El modelado de datos ayuda a definir y describir los datos según la necesidad de las diferentes partes interesadas. Por ejemplo, un gerente puede necesitar datos para la creación de reportes, pero el desarrollador usa los mismos datos para ejecutar la lógica del negocio.
  • Los requerimientos futuros se consideran en el modelado de datos, por lo que la aplicación sigue siendo sólida, flexible y escalable.

Para comprender los beneficios del modelo de datos, considere el siguiente ejemplo. Una aplicación de solicitud de compra tiene dos procesos diferentes: gestión del pedido y gestión del producto. Dos equipos de prueba están implementando la gestión del pedido y la gestión del producto al mismo tiempo, cada uno modelando su propia definición de un producto. Existe la posibilidad de que ambos equipos de prueba entreguen dos diseños diferentes para un producto en lugar de una definición reutilizable para toda la empresa. Esta situación genera que haya diferentes formas de detectar el mismo producto y duplicación de los datos. Por consecuencia, el mantenimiento se torna más difícil, la aplicación es menos flexible y no es escalable.

Nota: Si un elemento de datos ya existe, considere cómo se ajusta a sus requerimientos. Por ejemplo, cuando hay un 80 por ciento de coincidencia entre una clase de Pega y el objeto de negocio requerido, use los elemento de datos ya creados. Explore PegaData-* y compruebe los elementos que se puedan reutilizar, que estén compuestos de estas clases y que se puedan heredar de estas clases. De lo contrario, planee crear nuevos elementos de datos.

El diseño del modelo de datos trata sobre la organización y el diseño de los datos, pero no sobre las operaciones que se realizan en los datos. El tipo de caso es diferente de los datos que contiene. El tipo de caso realiza operaciones en los datos. Una de las finalidades principales de un caso es administrar los datos necesarios para completar un Microjourney o una transacción de negocio única. La finalidad principal de los datos es formar otros tipos de datos o que se los use en uno o más tipos de caso.

Al final del modelado de datos, es una buena idea representar los datos y sus relaciones con un diagrama de relaciones. App Studio crea este diagrama de relaciones, por lo que no es necesario usar herramientas de terceros para dibujar el diagrama de relación de datos. En la fase de diseño (antes de la implementación real en Pega), puede usar recuadros simples y conectores para representar el modelado de datos y comprenderlo con facilidad.

DataModelAtDesignTime_LSA86
Este diagrama es una ilustración de muestra de la relación de tipos de datos y tipos de casos para un escenario comercial de servicio de ferry (un examen de LSA que se ha reintentado). La representación gráfica es fácil de comprender y se puede reconocer rápidamente el modelo de datos para el escenario comercial determinado. Otra forma de representación de modelo de datos puede ser el formato de tabla, como se muestra a continuación  
DataModelInTableFormat2
Este diagrama muestra la representación del modelo de datos en formato de tabla, esta es una muestra para el servicio de ferry  
Nota: No es necesario incluir la captura de App Studio en el documento de diseño mientras se escribe en el examen de diseño de la app de LSA." data-embed-button="image_browser" data-entity-embed-display="view_mode:media.embedded" data-entity-embed-display-settings="" data-entity-type="media" data-entity-uuid="8b8f526d-ce1f-4c79-81cb-768f49487c2e">

 


This Topic is available in the following Module:

If you are having problems with your training, please review the Pega Academy Support FAQs.

¿Le ha resultado útil este contenido?

El 75% ha encontrado útil este contenido.

¿Quiere ayudarnos a mejorar este contenido?

We'd prefer it if you saw us at our best.

Pega Academy has detected you are using a browser which may prevent you from experiencing the site as intended. To improve your experience, please update your browser.

Close Deprecation Notice