Modelado de datos para Dataverse
Cuando almacena o visualiza datos con su aplicación, una parte importante del diseño es la estructura de datos. Debería considerar cómo se usarán los datos en una aplicación o pantalla específica, además de cómo los usarán otros. Hacer referencia a sus personajes, tareas, procesos comerciales y objetivos le ayudará a definir qué datos almacenar y cómo estructurarlos.
Tipos de tabla
Dataverse tiene tres tipos de tabla:
- Estándar: tablas en las que puede almacenar datos y agregarlos a la navegación en aplicaciones basadas en modelos. La mayoría de las tablas que cree serán estándar. En un entorno de Dataverse, se crean varias tablas estándar a partir del esquema Common Data Model.
- Actividad: estas tablas se utilizan para almacenar interacciones como llamadas telefónicas, tareas y citas. Un conjunto de tablas de actividades se encuentran en una base de datos de Dataverse.
- Virtual: estas tablas permiten crear la tabla y las columnas en Dataverse, pero luego se usa un origen de datos externo para almacenar los datos. Para el usuario, los datos aparecen en sus aplicaciones como cualquier otro dato.
Cuando crea una tabla estándar personalizada, debe especificar su propiedad:
- Usuario/equipo: opción predeterminada
- Organización: se utiliza para datos de referencia
Tablas de actividad personalizadas
Las tablas de actividades se usan para almacenar interacciones. Guardan relación con todas las tablas que tienen Habilitar para actividades establecido en los metadatos de tabla. Las tablas de actividades comparten el mismo conjunto de columnas y comparten los mismos privilegios de seguridad. Las filas de las tablas de actividades aparecen en la escala de tiempo en los formularios de aplicaciones controladas por modelos. En este ejemplo, se ha creado una tabla de actividad personalizada llamada Donación.
Ventajas de utilizar tablas de actividades personalizadas:
- Aparecen en una lista con otras actividades.
- Se pueden consolidar con otras actividades.
- Se puede crear una donación en cualquier tabla que admita actividades.
Los principales inconvenientes de utilizar tablas de actividades personalizadas es que no pueden:
- Configurar la seguridad diferente a cualquier otra actividad.
- Controlar qué tablas están relacionadas con una donación.
Tipos de datos de columna
Debe elegir con inteligencia el tipo de datos de las columnas. Esta noción es especialmente cierta en el caso de los tipos de datos numéricos, ya que no se pueden comparar columnas numéricas con diferentes tipos y existen restricciones sobre los tipos de datos de las columnas calculadas y consolidadas. Una vez que se ha elegido un tipo, no se puede cambiar.
| Tipo de datos | Comentarios |
|---|---|
| Sí/No | Asegúrese de que nunca necesite más opciones |
| Archivo e imagen | Permite almacenar archivos e imágenes en línea en Dataverse |
| Cliente | Puede ser un contacto o una cuenta. |
| Búsqueda/Opción | Asegúrese de elegir el mejor |
| Fecha/hora | Asegúrese de elegir el comportamiento apropiado |
| Numérico | Muchos que elegir, así que elija con inteligencia |
Tabla de opciones o tabla de búsqueda
La forma de decidir entre usar una tabla de búsqueda o una tabla de opciones depende de las circunstancias.
Utilice una tabla de opciones cuando desee una tabla con las siguientes características:
- Solo almacena la etiqueta y el valor como par clave-valor.
- Tiene la localización integrada.
- Se trata como componente de solución.
- No tiene una forma incorporada de retirar valores.
- Tiene una UX que funciona con unos 200 elementos.
- Se puede filtrar con JavaScript.
- Se almacena como un número entero en la fila.
Utilice una tabla de búsqueda cuando desee una tabla con las siguientes características:
- Puede almacenar otros datos en columnas en la fila.
- Requiere que cree la localización.
- Se trata como datos de referencia.
- Admite un estado inactivo.
- Tiene una UX que escala a muchos elementos.
- Se puede filtrar por vistas y seguridad.
- Se almacena como referencia de entidad.
El almacenamiento de otros datos en la tabla de búsqueda le permite acceder cuando ejecuta flujos de trabajo u otras personalizaciones que hacen referencia a los datos. Por ejemplo, una propiedad relacionada se puede utilizar en una condición de comprobación.
Al ser un componente de la solución, una tabla de opciones controla la resolución de la combinación agregando el prefijo del editor al valor.
Agregar valores en una tabla de opciones requiere acceso de nivel de administrador/personalizador, mientras que un usuario puede cambiar los valores de búsqueda si se le otorga permiso a través de roles de seguridad.
La experiencia del usuario (UX) para las opciones es ideal para cantidades pequeñas, pero no funciona bien para conjuntos grandes. Las búsquedas proporcionan funciones de tipo de búsqueda que no están disponibles en las opciones.
Si tiene columnas de opción múltiple que dependen unas de otras, esta tarea solo se puede lograr con un script basado en formularios, mientras que las búsquedas se pueden filtrar en otras búsquedas mediante configuración.
Almacenamiento de datos de archivos e imágenes
Tiene varias opciones de dónde almacenar archivos e imágenes:
- Dataverse: almacene archivos e imágenes utilizando los tipos de datos Archivo e Imagen.
- SharePoint: se usa para la colaboración, pero esta opción tiene un problema de seguridad. La seguridad de los archivos sigue los permisos de SharePoint y no está sincronizada con los permisos de fila de Dataverse.
- Azure Storage: se usa para archivado y acceso externo. Esta opción tiene seguridad independiente, pero se puede otorgar por pequeños períodos de tiempo según el vínculo generado para el consumo (patrón de valet). Azure Storage también puede ocuparse de archivos grandes.
Características de los tipos de datos de archivo e imagen:
- Son adecuados para carga y consulta.
- La seguridad sigue los permisos de registro.
- Están limitados por tamaño.
Columnas calculadas
Las columnas calculadas permiten realizar cálculos simples sobre los datos de una fila y:
- Se calculan al recuperar un registro.
- Tienen un valor de solo lectura.
- Pueden incluir columnas de la misma fila y columnas en relaciones de varios a uno.
- Pueden incluir columnas acumuladas en el cálculo.
- No pueden desencadenar un evento para el flujo de trabajo, el complemento o Power Automate.
Columnas consolidadas
Las columnas consolidadas permiten agregaciones para filas relacionadas en relaciones de uno a varios y:
- Se calculan sobre una base programada (mínimo una hora) y un usuario las puede actualizar a petición.
- Tienen un valor de solo lectura.
- Pueden consolidar columnas calculadas.
- Pueden usar una jerarquía de registros relacionados.
- Pueden filtrar tablas relacionadas.
- No pueden desencadenar un evento para el flujo de trabajo, el complemento o Power Automate.
Pueden consolidar columnas calculadas "simples"; es decir, las columnas calculadas que incluyen funciones no deterministas no se pueden consolidar.
Relaciones
Las relaciones definen cómo se relacionan las filas entre sí en Dataverse. Cada tabla de Dataverse tiene una clave principal para proporcionar una referencia única a las filas de la tabla. En Dataverse, la clave principal es un identificador único global (GUID) que Dataverse genera automáticamente cuando se crea una fila. Las relaciones se crean agregando una referencia a la clave principal, que se conoce como clave extranjera. En Dataverse, las relaciones se crean mediante el uso de una columna en una tabla para contener el valor de la clave extranjera. Esta clave extranjera es un puntero a la clave principal en la otra tabla.
En Dataverse se admiten dos tipos de relaciones:
- Uno a varios (1:N)
- Varios a varios (N:N)
Relación de uno a varios
El siguiente informe de gastos muestra un ejemplo de relación de uno a varios (1:N).
La captura de pantalla anterior muestra la parte principal del informe de gastos, que tiene el nombre del empleado y los detalles del departamento. Debajo de la parte principal, hay varias filas de descripciones para cada artículo comprado. Para este ejemplo, estas descripciones se llamarán elementos de línea. Los elementos de línea individuales tienen una estructura diferente a la parte principal del informe de gastos. Por lo tanto, cada informe de gastos tiene varios elementos de línea.
La relación entre el informe de gastos y el elemento de línea es un ejemplo de una relación de uno a varios (1:N). La parte principal del informe de gastos está vinculada a varios elementos de línea. También puede ver la relación desde la perspectiva de los elementos de línea: cada elemento de línea solo se puede vincular a un informe de gastos, que es una relación de varios a uno (N:1).
Relación de varios a varios
Una estructura de datos de varios a varios es un tipo especial y se utiliza para los casos en los que se pueden asociar varios registros con varios conjuntos de otros registros. Un buen ejemplo de una estructura de datos de varios a varios es su red de socios comerciales. Tiene varios socios comerciales (clientes y proveedores) con los que trabaja y esos socios comerciales también trabajan con varios colegas suyos.
Las siguientes secciones proporcionan ejemplos de diferentes tipos de estructuras de datos de varios a varios.
Ejemplo 1: solicitud de aprobación de indisponibilidad
El siguiente ejemplo muestra dos conjuntos de datos: uno que representa al empleado y el otro que representa la solicitud de indisponibilidad. Debido a que cada empleado enviará múltiples solicitudes, la relación en este escenario es de uno a varios, donde "uno" es el empleado y "varios" son las solicitudes. Los datos del empleado y los datos de la solicitud de indisponibilidad están relacionados entre sí al tener el número de empleado como columna común (también conocida como clave).
Ejemplo 2: aprobación de compra
En este ejemplo, la estructura de datos parece sofisticada pero es similar al ejemplo del informe de gastos que se analizó al principio de este artículo. Cada vendedor o proveedor está asociado a múltiples pedidos de compra. Cada empleado está a cargo de múltiples pedidos de compra. Por lo tanto, ambos conjuntos de datos tienen una estructura de datos de uno a varios.
Dado que es posible que los empleados no siempre utilicen el mismo vendedor o proveedor, los proveedores son utilizados por varios empleados y cada empleado trabaja con varios proveedores. Por lo tanto, la relación entre empleados y proveedores es de varios a varios.
Ejemplo 3: informe de gastos
El siguiente ejemplo muestra un diagrama de relación entre entidades (ERD) que contiene varias tablas para una solución de informes de gastos.
Ejemplo 4: seguimiento de las dos prestaciones que seleccionó el VIP
En este ejemplo se presentan dos VIP: John y Mary. John ha elegido las prestaciones de Wi-Fi y lavandería, y Mary ha elegido las prestaciones de Wi-Fi y minibar. Puede ejemplificar este escenario de formas diferentes. La primera forma es modelar el escenario como una relación 1:N.
En esta configuración:
- El registro de prestaciones es exclusivo para el contacto.
- No existe la posibilidad de ver todos los contactos que eligen una determinada prestación.
- Puede aplicar la seguridad del registro de prestaciones según el propietario del contacto.
- Puede almacenar más datos en el registro de prestaciones específico del contacto.
- La relación es jerárquica para la prestación, de lo contrario quedarán huérfanos los registros de prestaciones.
La segunda forma es modelar el escenario como una relación N:N.
En esta configuración:
- Los registros asociados de la prestación, se muestran todos los contactos que eligen esa prestación.
- La seguridad de la prestación se comparte para todos los contactos, por lo que no tendrá posibilidad de adaptarse a cada contacto.
- Todos los atributos de la prestación se comparten para todos los contactos, por lo que no tendrá datos específicos del contacto.
- Debe usar una relación de referencia; de lo contrario, estaría eliminando la prestación de otros contactos.
Ninguna configuración es ideal.
El siguiente ejemplo muestra la creación de una tabla personalizada (entre conjuntos) para contener las prestaciones del VIP.
Esta configuración:
- Agrega la capacidad de almacenar más datos en la tabla de prestaciones específica de ese contacto.
- Requiere más trabajo para el usuario, que debe conectar los registros; ahora tiene que crear la fila de intersección manualmente.
- Protege las prestaciones individualmente.
- Hace que las consultas sean más difíciles, ya que no tiene la capacidad de acceder directamente a los atributos de la tabla de prestaciones.
El siguiente ejemplo muestra el uso de columnas en la tabla de contactos.
Esta configuración:
- Funciona bien para las prestaciones primarias y secundarias, pero no se adaptaría al seguimiento de muchas prestaciones.
- Simplifica la consulta y hace que el Power BI de autoservicio sea más fácil para los usuarios.
- Sigue la misma seguridad que el registro de contacto.
- Requiere que cree una consulta que analice las prestaciones primarias y secundarias si va a consultar todos los usuarios que elijan una prestación principal.
Esta configuración es un buen ejemplo de cuando la prestación debe registrarse para algún propósito de cumplimiento/estadístico, pero no tiene ningún impacto en el negocio o el procesamiento.
Comportamientos de relaciones
Los comportamientos de relaciones controlan cómo ciertas acciones descienden en cascada hacia las filas que están relacionadas con la fila de la tabla principal a través de la relación 1:N. Los comportamientos mantienen la integridad referencial y pueden evitar que los registros huérfanos se queden atrás.
Importante
La definición de comportamientos de relación es importante, porque la cascada de registros asignados puede hacer que se asignen registros relacionados. En caso de duda, establezca el comportamiento en Referencial y Restringir.
Claves alternativas
Las claves alternativas se utilizan en integraciones para reducir la necesidad de realizar una consulta para encontrar un registro. Al usar una clave alternativa, puede actualizar una fila sin conocer su GUID.
Claves alternativas:
- Son excelentes para usar en recuperaciones y actualizaciones.
- Puede contener decimales, números enteros, campos de texto, fechas y campos de búsqueda.
- Puede tener hasta cinco claves alternativas para cada tabla.
- Cree un índice único que acepte valores NULL en segundo plano para imponer la exclusividad de la clave.
Cuando se crea una clave, el sistema valida que esa clave pueda ser compatible con la plataforma.
Prácticas recomendadas para el diagrama
Al crear ERD para Dataverse, debería:
- Evitar la duplicación de datos. Cada dato debe tener solo un lugar. En lugar de duplicar los mismos datos entre varias tablas, se deben usar funciones como formularios de vista rápida y mostrar datos de tablas relacionados en las vistas.
- Utilice las relaciones de ERD para revisar e identificar posibles comportamientos en cascada que podrían afectar a la lógica empresarial. Por ejemplo, con las relaciones parentales, los permisos como Asignar, Compartir, Dejar de compartir, Cambiar primario, Eliminar y Combinar se aplicarán automáticamente a los registros relacionados cuando se actualice un registro principal.