Skip to main content

Implementación de un modelo de datos eficaz

4 Tareas

45 minutos

Visible to: All users
Avanzado Pega Platform 8.6 Español

Escenario

Imagine que el equipo de reservas todavía está en la fase de diseño de su proyecto; no se produce ningún desarrollo. La primera tarea del equipo de reservas es revisar el conjunto actual de clases de datos de nivel empresarial desarrollado por el equipo del Centro de Excelencia (COE) de FSG. Esta tarea tiene como objetivo ver las clases de datos que puede reusar el equipo de reservas en su diseño. Durante su análisis, es probable que el equipo de reservas descubra clases de datos que el equipo COE de FSG no ha definido. A continuación, el equipo de reservas debe decidir si esas clases de datos no definidas son dignas de ser definidas a nivel empresarial o si, en cambio, son propiedad del equipo de reservas.

La siguiente tabla incluye las credenciales que necesita para completar el reto.

Función Nombre de usuario Contraseña
Administrador COE@FSG reglas
Administrador Admin@FSGPricingTest reglas
Administrador Admin@Booking reglas

Debe iniciar su propia instancia de Pega para completar este Título del desafío.

La inicialización puede demorar hasta 5 minutos. Le pedimos que tenga paciencia.

Tareas detalladas

1 Análisis del modelo de datos del Centro de Excelencia de FSG

Después de iniciar sesión como administrador@FSGPricingTest y COE @FSG, observa un patrón. Las clases que se muestran en la vista Data Types de cada aplicación son las que posee la aplicación. La aplicación es principalmente responsable de probar, mantener y definir cómo se empaquetan e implementan esos tipos de datos.

Aplicación/Operador

Tipos de datos propios

Tipos de datosde solo prueba

Comment (Comentario)

FSGPricingTest

Admin@FSGPricingTest

(FSG-Data-)

Price, Priceable, Pricing, PricingInit, PricingPropertySource, PricingSummary

(FSG-PricingTest-Data-)

PricingDisplay

La aplicación FSGPricingTest tiene cuatro propósitos:

  1. La regla del producto crea las tablas de esquema CustomerData para el componente Pricing
  2. Incluye el componente Pricing en su regla de aplicación. La regla de producto también incluye el componente
  3. Prueba el componente Pricing
  4. Demuestra cómo usar el componente Pricing dentro de una aplicación

FSG

COE@FSG

(FSG-Data-)

Address, Constant, Contact, Feedback, Hotel, Location, Venue

N/D

La aplicación FSG contiene clases de capa organizacional o empresarial. Estas clases describen la estructura de los objetos que comparten varias aplicaciones dentro de la organización. Los objetos generalmente se identifican con sustantivos y representan "personas", "lugares" o "cosas".

  • Las aplicaciones comerciales aprovechan las clases de datos estandarizados que definen personas y lugares.
  • Constante y feedback son “cosas”.
  • Los demás tipos de datos propiedad de la aplicación FSG son una persona (contacto) o tienen algo que ver con un lugar (dirección, ubicación, hotel, lugar).

FSGEmail

COE@FSG

Ninguno

N/D

  • La aplicación FSGEmail no define ningún tipo de datos.
  • La aplicación FSGEmail define un registro relevante para la propiedad Work- WhenToSendEmail.
  • FSG tuvo problemas para definir un registro relevante aplicado a Work-, por lo que definió uno que se aplica a la clase FSG-Email-Work-Email.

FSGSample

COE@FSG

N/D

(FSG-Sample-Data-)
Vehicle, Car, Truck, Motorcycle, RoadsideService

  • La aplicación FSGSample se usa para probar y demostrar cómo usar los tipos de datos que posee la aplicación FSG. 
  • FSGSample no incluye los tipos de datos definidos por FSG que prueba dentro de su propia vista Tipos de datos. Esto se hace para comunicar qué aplicación es propietaria de qué tipos de datos. Evita la redundancia del empaquetado de tipos de datos.

FSGSample2

COE@FSG

N/D

(FSG-Sample2-Data-)

Vehicle2, Car2, Truck2, Motorcycle2

  • La aplicación FSGSample2 se usa para demostrar la referencia de clase dinámica (DCR) de clase de datos.
  • La vista Tipo de datos también incluye FSG-Sample-Data-Vehicle y FSG-Sample-Data-RoadsideService.
  • La clase Vehicle se agrega a la vista Tipo de datos para permitir que se vean las instancias.
  • FSGSample posee la tabla Vehicle, no FSGSample2.
  • FSGSample2 extiende directamente cada clase FSG-Sample-Data-Vehicle; esto se hace para demostrar cómo es posible extender una clase de datos definida por el esquema CustomerData y, al mismo tiempo, conservarla en la misma tabla de base de datos. La aplicación FSG hace esto con Location y con las clases que extienden directamente Location.

Desde la aplicación de FSG, el equipo de reservas reutiliza las clases Contacto, Dirección y Ubicación; la omisión de esta acción no se puede justificar.

La clase Constant es reusable. El uso de la clase Constant  evita la codificación de valores que la empresa puede querer ajustar, controlar y mantener. La aplicación FSGSample no define un tipo de datos de solo prueba para demostrar cómo se usa la clase Constant. En cambio, la aplicación FSGSample usa la clase FSG-Sample-Work-TestConstants para demostrar cómo se puede usar la clase FSG-Data-Constant. El equipo de reservas debe decidir un enfoque, ya sea definir un tipo de datos ConstantProps o usar la configuración de la aplicación o algo intermedio.

La aplicación Booking (Reservas) puede usar potencialmente la clase Feedback después de la conclusión de un evento. La clase se usa para capturar datos del cliente sobre qué tan bien FSG organizó el evento.

El equipo de reservas tiene inquietudes sobre la clase Feedback. La aplicación FSGSample no demuestra cómo usar la clase Feedback. Actualmente, la clase Feedback es abstracta y contiene solo dos propiedades. Faltan otros tipos de reglas, como secciones o data transforms. El equipo de reservas también se pregunta si un gestor de eventos debe completar los valores después de comunicarse con el cliente o si el enfoque automatizado interactúa con un formulario de encuesta de Pega.

La primera etapa en la aplicación Booking (Reservas) consiste en cotizar el precio a un cliente (contacto) para realizar un evento en un lugar determinado. La aplicación Booking (Reservas) puede reusar los tipos de datos que posee la aplicación FSGPricingTest. Hay un tipo de datos de solo de prueba denominado PricingDisplay, que está definido por la aplicación FSGPricingTest; este es un indicio de que la aplicación Booking (Reservas) debe definir su propia clase PricingDisplay.

2 Análisis del modelo de datos del equipo de reservas

La clase Constant del COE de FSG tiene propiedades como Application, CaseUsage, Description y DataType. La aplicación FSGSample del COE de FSG contiene dos casos de prueba relacionados con su tipo de datos FSG-Data-Constant.

El caso TestAppConstantsLibrary de FSGSample define una página de datos D_FSGSampleConstants que origina un data transform denominado LoadConstantsForClass. El equipo de reservas sigue este ejemplo para definir las páginas de datos D_BookingConstantProps, D_HotelConstantProps y D_WeatherConstantProps.

El equipo de reservas consideró usar configuraciones de aplicaciones categorizables. Al equipo de reservas le gusta cómo la solución de COE de FSG admite la sintaxis de ruta de puntos para una propiedad con un tipo de datos que no sea texto.

Específicamente para la aplicación de reservas, al equipo de reservas le gusta cómo el COE de FSG modeló una pantalla de cotización de eventos de ejemplo en la que se usó un tipo de datos PricingDisplay. El componente de precios admite un parámetro de nombre de página PricingDisplayPage dentro de tres data transforms: Work-WorkRecalculatePrices, @baseclass RecalculatePrices y FSG-Data-Pricing Recalculate. La capacidad está ahí; el equipo de reservas también podría usarlo. Si lo hace, se ahorra el tiempo y el esfuerzo dedicados a crear esa funcionalidad por sí mismo.

El equipo de reservas creó una tabla como la que se usa para analizar y revisar el modelo de datos del COE de FSG. La columna Test-Only Data Types se reutiliza como una columna New Data Types where ownership is undecided.

Aplicación/Operador

Tipos de datos propios/compartidos

Nuevos tipos de datos donde la propiedad no se ha decidido

Comment (Comentario)

Reserva

Admin@Booking

(FSG-Booking-Data-)

BookingConstantProps, PricingDisplay

(FSG-Data-Feedback-)
EventVenue  (concreto)

Evento

La aplicación Booking (Reservas) cita el evento de un cliente y las fechas de inicio y finalización. Los subcasos se separan según sea necesario. Esos subcasos no se deben separar de inmediato; cada uno espera hasta el momento apropiado antes del evento.

Hotel/HotelProxy

Admin@HotelDevOnly

(FSG-Data-Hotel-)

HotelConstantProps, RoomsRequest

 

La aplicación Hotel debe comunicarse con una aplicación HotelProxy separada por varias razones. Las dos aplicaciones están alojadas en bases de datos diferentes. La aplicación HotelProxy no necesita acceso a otro código que no sea el suyo propio y el de FSG. La aplicación Hotel necesita acceso a FSGEmail.

Pronóstico meteorológico

Admin@Booking

(FSG-WForecast-Data-)

WForecastConstantProps,

Clima, Precipitación, Pronóstico

 

La aplicación Weather Forecast (Pronóstico meteorológico) tiene como objetivo pronosticar el clima antes de un evento y luego ayudar a determinar si debe realizarse una preparación debido a la probabilidad de lluvia.

Estacionamiento

Admin@Booking

(FSG-Parking-Data-)

ParkingConstantProps, ParkingLot, ParkingGarage

ParkingLocation

La aplicación Parking tiene como objetivo registrar la cantidad de autos estacionados dentro de cada estacionamiento o garaje seleccionado cerca de la ubicación de un evento.

Transporte

Admin@Booking

(FSG-Shuttle-Data-)

ShuttleConstantProps, ShuttleCompany, ShuttleVan, ShuttleTrip

Viaje, vehículo, empresa

La aplicación Shuttle (Transporte) tiene como objetivo interactuar con las empresas de transporte para garantizar el transporte rápido de ida y vuelta de los asistentes al evento desde o hacia un lugar de celebración u otro tipo de ubicación, por ejemplo, un hotel o un estacionamiento. La aplicación Shuttle puede aplicar el principio de “del centro hacia afuera”, ya que conoce en qué ubicación es más urgente transportar a los asistentes. Cuando un conductor de transporte realiza solicitudes en una tableta o un teléfono inteligente, la aplicación Shuttle dirige al conductor a la siguiente mejor ubicación de recogida.

El caso BookEvent del equipo de reservas necesita capturar información sobre un evento, como su fecha de inicio y finalización.  Organizar un evento es fundamental para el modelo de negocio de FSG; sin embargo, el caso BookEvent de la aplicación Booking (Reservas) es el único lugar, hasta ahora, donde se usa un tipo de datos de evento.

El equipo de reservas puede ampliar la clase FSG-Data-Hotel  propiedad de COE para su aplicación Hotel, pero no ve una necesidad inmediata de hacerlo.

El equipo de reservas podría extender la clase abstracta FSG-Data-Feedback para formar una clase concreta FSG-Data-Feedback-EventVenue. El equipo de reservas recomienda que el COE de FSG agregue una propiedad de referencia a FSG-Data-Feedback. Una definición de reportes se especifica dentro de la clase -EventVenue y realiza un JOIN a FSG-Booking-Work-BookEvent y un JOIN a la propiedad de referencia BookEvent case.VenueGUID a FSG-Data-Venue. El nombre del lugar puede cambiar desde el último registro de datos. Definir un JOIN con una propiedad de nombre no es una práctica recomendada, y es una violación de la integridad de los datos. El nombre del lugar se puede registrar por razones históricas, pero el nombre de la propiedad debe reflejar ese hecho (por ejemplo, .HistoricalVenueName).

La extensión del equipo de reservas de FSG-Data-Feedback can  se incorporará a la aplicación FSGSample2 para que otros equipos de desarrollo de nivel superior conozcan qué es posible hacer. En la lista de tareas pendientes de FSG, se encuentra el desarrollo de una forma común de enviar una encuesta de Pega, recibir la respuesta y luego persistir la respuesta en la capacidad adecuada FSG-Data-Feedback

Los datos persistentes no incluyen una propiedad en la que un Net Promoter Score se haya convertido en una categoría (promotor, pasivo, detractor). Si lo hicieran, también constituiría una violación de la integridad de los datos. Una definición de reportes puede usar una función SQL parametrizada de tres entradas personalizadas para derivar una categoría. El primer parámetro se completa con la propiedad de puntaje de promotor sin procesar. El segundo y tercer parámetro son el inicio y el final del rango de números enteros de la categoría (por ejemplo, 0 y 6 son el inicio y el final del rango “detractor”). La función SQL personalizada genera 1 si el primer parámetro se encuentra dentro del rango. De lo contrario, da como resultado 0. La definición de reportes agrega la columna mediante la función estandarizada de SQL SUM().

La aplicación Hotel y la aplicación Hotel Proxy se comunican mediante la API RESTful de Pega. Por varios motivos, como el tamaño de la aplicación, la seguridad y la facilidad de mantenimiento, la aplicación Hotel Proxy no se desarrolla sobre la base de la aplicación Hotel. Se debe definir un tipo de datos de RoomsRequest en el nivel de COE de FSG para que ambas aplicaciones hereden la base. Las aplicaciones Hotel y Hotel Proxy deben usar otro mecanismo para compartir la clase. Sin embargo, es necesario compartir las clases de integración REST que usan ambas aplicaciones. La conclusión lógica fue desarrollar un componente para albergar las clases compartidas y el código relacionado.

El COE no ha definido un conjunto de tipos de datos relacionados con el pronóstico del tiempo. Por lo tanto, el equipo de reservas debe decidir si su aplicación de pronóstico meteorológico posee esos tipos de datos. La previsión meteorológica no es imprescindible en el modelo de negocio de FSG. ¿Deberían otras aplicaciones usar los mismos tipos de datos de pronósticos meteorológicos pero ignorar la preparación meteorológica? ¿Qué impacto hay si el código para realizar ambos se empaqueta en conjunto? La suposición es que el código de pronóstico del tiempo es liviano.

La aplicación de estacionamiento se ocupa de diferentes tipos de ubicaciones, como estacionamientos o garajes. Los asistentes a un evento que deseen estacionar cerca querrán ver sus opciones de estacionamiento en un mapa.

La aplicación de transporte puede manejar cualquier ubicación, ya sea un lugar, un hotel o un espacio de estacionamiento. Este conocimiento refuerza la noción de que el COE de FSG debe definir una clase ParkingLocation. El equipo de reservas puede heredar esa clase directamente o heredar patrones, según sea necesario.

Finalmente, la aplicación Shuttle requiere tipos de datos relacionados con viajes de transporte. El equipo de reservas puede definir sus tipos de datos, pero ¿pueden otras aplicaciones aprovechar una abstracción de esos tipos de datos, como viaje, vehículo y empresa?

3 Decidir quién posee tipos de datos indecisos

Organizar un evento es fundamental para la línea de negocio de FSG. Existe la posibilidad de que otras aplicaciones dentro de FSG, como Billing y Advertising, usen la misma definición de tipo de datos. A medida que pasa el tiempo, otras aplicaciones pueden agregar propiedades a FSG-Data-Event. Un cliente puede ponerse en contacto con un miembro del equipo de reservas para preguntar cómo se factura el alojamiento de un evento. La seguridad ABAC de lectura de propiedades se puede aplicar para enmascarar información que solo los miembros del equipo de facturación deberían poder ver. El miembro del equipo de reservas puede transmitir la información que el miembro del equipo puede ver y luego derivar al cliente al equipo de facturación si el cliente desea información detallada.

Una práctica recomendada es estandarizar las definiciones de personas y lugares en una empresa. Se recomienda que el COE de FSG mantenga las definiciones básicas para las clases que extienden FSG-Data-Location. Una razón para hacerlo es que las ubicaciones se almacenan en la misma tabla de esquema CustomerData. Cuando se crea la aplicación de transporte, se debe definir un viaje como si tuviera lugar en dos ubicaciones cualquiera, independientemente del tipo de ubicación. Es mejor dejar que el COE de FSG tome posesión de una clase ParkingLocation.

La siguiente tabla registra las decisiones tomadas con respecto al conjunto original de tipos de datos no definidos.

Aplicación

Nuevos tipos de datos donde la propiedad no se ha decidido

¿Debe ser propiedad del COE de FSG?

Reserva

Evento

Estacionamiento

ParkingLocation

Transporte

Viaje, vehículo, empresa

Por determinar

Se desconoce cuándo se debe iniciar el desarrollo de la aplicación Shuttle. El equipo de reservas sin duda puede beneficiarse si el COE de FSG diseña un modelo de datos abstracto donde cualquier Vehicle con una capacidad limitada hace Trips entre dos Locations. Con toda probabilidad, el Company propietario del Vehicle no es FSG. FSG no quiere que sus empleados se conviertan en despachadores de transporte a tiempo completo. En cambio, FSG quiere automatizar la toma de decisiones tanto como sea posible. Por ejemplo, el sistema funciona solo sin supervisión. La dependencia excesiva de los datos obsoletos podría conducir a una situación de “basura que entra = basura que sale”. La solución debe ser capaz de aceptar datos en tiempo real y tomar decisiones en tiempo real.

4 Complete las siguientes tareas

Dibuje el modelo de datos para la aplicación Shuttle. La definición del modelo de datos incluye el modelo de datos para cada tipo de caso, no solo los tipos de datos de extensión de clase de datos.

Para cada clase de modelo de datos, muestre lo siguiente:

  • El nombre completo de la clase y qué clase se extiende
  • Si la clase es abstracta o concreta
    • Si es concreta, la clase muestra el esquema en el que se conservan las instancias
  • Propiedades usadas para las relaciones de datos
    • Indique que es embebida o, si es una referencia, agregue Ref al nombre de la propiedad
    • Indique que es una lista si corresponde
  • Propiedades escalares críticas
Nota: Un diagrama de interacción puede ayudar a obtener una mejor perspectiva del dominio del problema, especialmente la sincronización de las entradas recibidas por el sistema.


Disponible en la siguiente misión:

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

¿Le ha resultado ú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