Implementación de un modelo de datos eficaz
4 Tareas
45 minutos
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 |
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:
|
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".
|
FSGEmail COE@FSG |
Ninguno |
N/D |
|
FSGSample COE@FSG |
N/D |
(FSG-Sample-Data-) |
|
FSGSample2 COE@FSG |
N/D |
(FSG-Sample2-Data-) Vehicle2, Car2, Truck2, Motorcycle2 |
|
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 |
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 |
Sí |
Estacionamiento |
ParkingLocation |
Sí |
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
Disponible en la siguiente misión:
¿Quiere ayudarnos a mejorar este contenido?