Una presentación de un diccionario de datos debe resolver un desacuerdo sobre el significado, no proyectar una hoja con todas las columnas. Empieza por una pregunta de negocio que las personas ya interpretan de forma distinta. Relaciónala con unos pocos registros, acuerda la definición y explica quién la mantiene y qué cambia en los informes que la utilizan.
Imagina una empresa ficticia que trabaja con citas. Su panel indica «tres citas completadas», pero la responsable de operaciones afirma que solo un cliente recibió el servicio. Ninguna de las dos partes ha inventado la cifra: el panel cuenta citas cerradas, incluidas cancelaciones e inasistencias. La etiqueta hace que tres resultados distintos parezcan lo mismo. Todos los registros, roles y cambios del ejemplo son inventados para mostrar una revisión del diccionario; no son datos de clientes ni una implementación de Presenti.
Cuando el equipo haya acordado las definiciones, el flujo de Presenti para crear presentaciones a partir de texto puede convertir la explicación aprobada en diapositivas editables. Pega las definiciones seleccionadas y las filas de ejemplo, no una exportación confidencial de la base de datos. El diccionario sigue siendo la fuente de referencia; la presentación es una vista reducida, adaptada a la audiencia, para tomar una decisión.
Empieza por el término que provocó el desacuerdo
En este ejemplo participan la responsable de operaciones, el analista de informes y el ingeniero responsable de exportar los datos de reservas. Deben aprobar qué significa «cita completada» antes de la próxima versión del informe. No necesitan un recorrido por todos los campos del sistema.
Un diccionario útil conecta el lenguaje de las personas con los datos que pueden examinar. La guía del USGS sobre diccionarios de datos incluye nombres, definiciones, tipos de datos, admisión de valores nulos, valores de referencia y reglas de negocio. En esta reunión, esos detalles deben responder a una pregunta concreta: ¿la fila representa un servicio prestado o solo una cita que ya no va a celebrarse?
Define el alcance en la primera diapositiva: «Una fila por cita en la instantánea diaria de reservas de una ubicación». En este ejemplo, la instantánea se tomó a las 08:00 UTC del 9 de octubre de 2026: refleja el estado en ese corte, no el estado más reciente de hoy. Muestra esa hora y la versión del diccionario. Una cita no es un cliente; el mismo cliente puede tener varias citas. Una instantánea tampoco es un historial de todos los cambios de estado. Estas dos distinciones evitan usos plausibles, pero incorrectos, de datos válidos.
| ID de cita | Estado en la instantánea | Hora de finalización, UTC | Interpretación de negocio |
|---|---|---|---|
| 000271 | completed | 2026-10-08T09:30:00Z | El servicio consta como prestado. |
| 000272 | cancelled | Sin valor | La reserva se canceló; no es un servicio prestado. |
| 000273 | no_show | Sin valor | El cliente no acudió; no es un servicio prestado. |
| 000274 | booked | Sin valor | En esta instantánea todavía no consta un resultado final. |
Con la regla antigua, completed, cancelled y no_show son estados cerrados, de modo que el total mostrado es tres. Con la definición propuesta de completada, solo cumple 000271. La cuarta fila no debe convertirse silenciosamente en otra inasistencia porque la fecha de la cita ya haya pasado. En esta extracción, su resultado sigue sin resolverse.
Separa el formato de un campo de su significado de negocio
El tipo indica qué forma puede tener el valor. La definición explica qué representa. Un valor con aspecto de fecha no dice si corresponde a la reserva, al servicio o a la exportación. Del mismo modo, un identificador con aspecto numérico no tiene por qué ser una cantidad que se pueda sumar o redondear.
| Campo | Tipo y valores permitidos | Definición | Uso incorrecto que evitar |
|---|---|---|---|
appointment_id | Cadena obligatoria; única dentro de la instantánea. | Identificador estable de una cita, por ejemplo 000271. | No convertirlo en número y perder los ceros iniciales; no es un ID de cliente. |
service_date | Fecha obligatoria, YYYY-MM-DD. | Fecha programada del servicio en la zona horaria Europe/London de la ubicación. | No sustituirla por la fecha de creación de la reserva ni por una fecha obtenida al truncar una marca temporal UTC. |
status | Cadena obligatoria: booked, completed, cancelled o no_show. | Estado registrado de la cita en el momento de la instantánea. | No utilizar closed como sinónimo de completed; closed es una agrupación derivada independiente. |
completed_at | Marca temporal UTC o valor ausente. | Hora registrada de finalización del servicio. | Un valor ausente no significa medianoche, duración cero ni inasistencia confirmada. |
El vocabulario de metadatos para datos tabulares del W3C permite describir tipos de columna, valores obligatorios, claves y otras restricciones en metadatos legibles por máquinas. Esa validación puede detectar valores mal formados o ausentes. No puede decidir por sí sola si tu negocio debe contar una cita cancelada como completada. Mantén juntas la restricción técnica y la definición de negocio, pero no las confundas.
Para una audiencia de negocio, muestra una fila y un error posible junto al campo, en vez de empezar por todos los términos de bases de datos. Los ceros iniciales de 000271 explican enseguida por qué el tipo es cadena. La diferencia entre fecha del servicio y hora de finalización hace que la regla de zona horaria merezca una conversación, en lugar de parecer una nota técnica irrelevante.
Explica los valores ausentes y los datos contradictorios
En la extracción de cuatro filas, falta la hora de finalización en tres estados distintos. En una cancelación es esperable. En una inasistencia también, pero por otro motivo. En una reserva sin resultado final, solo indica que no consta la finalización. Sustituir los tres casos por «no completada» puede facilitar un cálculo, pero elimina distinciones que el equipo necesita para gestionar el trabajo.
Añade ahora un quinto registro hipotético en la reunión. Este registro constituye una excepción: tiene estado completed, pero no hora de finalización. Operaciones puede saber que el servicio se prestó; el analista no puede deducir la hora a partir de esa fila. La regla propuesta consiste en clasificarla como excepción a la definición, investigarla y mostrar el número de excepciones excluidas junto al total de citas completadas. No reescribas el estado original solo para cuadrar el informe.
Es una decisión importante, no una norma universal. Otro negocio podría aceptar el estado por sí solo como evidencia de finalización. En ese caso, debe documentar esa política y definir cuándo se exige una hora. Lo peligroso es que dos autores de informes elijan políticas distintas sin hacer visible la diferencia.
| Entrada de la ficha | Propuesta para la reunión de aprobación |
|---|---|
| Término de negocio | Cita completada. |
| Significado | Una cita registrada como servicio prestado, con una hora de finalización registrada. |
| Registros incluidos | status es completed y completed_at contiene un valor. |
| Registros no incluidos | cancelled, no_show y booked; los registros completed sin la hora obligatoria se presentan por separado como excepciones. |
| Unidad y alcance | appointment_id distintos, no clientes distintos; una ubicación y una instantánea fechada. |
| Criterio temporal | El periodo del informe utiliza service_date en Europe/London; completed_at se conserva en UTC. |
| Correspondencia con la fuente | Instantánea diaria de reservas: appointment_id, service_date, status, completed_at. |
| Autoridad y versión | Operaciones aprueba el significado; el analista mantiene la ficha; propuesta de diccionario v2.0. |
| Limitación conocida | La instantánea actual, por sí sola, no permite reconstruir el estado en un corte anterior del informe. |
Puedes reutilizar las entradas de la izquierda para otro término discutido, pero sustituye toda la columna derecha. «Cliente activo», «solicitud resuelta» e «ingreso reconocido» necesitan reglas de inclusión y autoridades distintas. Cambiarles solo el nombre no produciría definiciones válidas.
Asigna responsables del significado, la correspondencia y los cambios
Una fila que dice «responsable: equipo de datos» suele ocultar tres preguntas: ¿quién puede aprobar el significado?, ¿quién puede corregir la correspondencia con la fuente? y ¿quién avisará a los usuarios de los informes de que el significado cambió? En el equipo ficticio, asigna esas tareas por separado.
- Responsable de operaciones: aprueba si un servicio prestado requiere una hora de finalización y resuelve las excepciones operativas.
- Ingeniero del sistema de reservas: confirma cómo llegan a la exportación los estados y las horas, incluidos retrasos y comportamiento de las correcciones.
- Analista de informes: mantiene la entrada del diccionario, identifica los informes afectados y registra la versión aprobada.
- Responsable del panel: modifica la etiqueta y la fórmula y aporta ejemplos que la persona responsable de negocio pueda aceptar.
Son responsabilidades del ejemplo, no una obligación de crear cuatro puestos. Un equipo pequeño puede combinar roles, pero la decisión debe seguir teniendo una persona responsable identificada y una vía de contacto útil. El ingeniero no debería inventar una definición comercial ni la persona responsable de negocio aprobar una correspondencia que nadie ha verificado.
Deja fuera de la aprobación lo que sigue pendiente. El equipo aún no ha acordado si una penalización por inasistencia debe formar parte de los ingresos de este informe. La presentación no debe insinuar que aclarar la definición de cita resuelve el reconocimiento de ingresos, los reembolsos o el tratamiento fiscal. Son términos diferentes, con otros registros de origen y otros responsables de decisión.
Muestra cómo afecta el cambio de definición al histórico
La versión v2.0 propuesta separa dos términos: cita cerrada y cita completada. La etiqueta antigua «completada» apuntaba a la regla más amplia de cerrada. Cambiar solo la etiqueta o solo la fórmula dejaría a los usuarios comparando cifras que no representan lo mismo.
| Versión del informe | Término mostrado | Regla | Recuento |
|---|---|---|---|
| v1.0, panel antiguo | Completada | completed, cancelled o no_show | 3 |
| v2.0, agrupación aclarada | Cerrada | completed, cancelled o no_show | 3 |
| v2.0, nueva medida operativa | Completada | completed con una hora de finalización registrada | 1 |
El paso de tres a uno no demuestra que el servicio haya empeorado. Los registros son idénticos; lo que ha cambiado es la definición. Muestra esta conciliación antes de presentar una serie temporal que atraviese la fecha de cambio.
Para el despliegue ficticio, se propone aplicar v2.0 desde la semana de informes que comienza el 2 de noviembre de 2026. Conserva el diccionario v1.0 y los informes exportados. Cuando las instantáneas guardadas contengan los campos necesarios, calcula un histórico recalculado independiente y etiquétalo como v2.0. Cuando no los contengan, mantén las series separadas e identifica la ruptura. Una exportación del estado actual no puede recrear de forma fiable todos los cortes históricos.
El registro del cambio debe identificar la regla anterior, la nueva, el periodo de aplicación, quién aprueba, los informes afectados y el tratamiento del histórico. Indica también si cambia la exportación de origen o solo su interpretación. Aquí, la exportación se mantiene; cambian a la vez la definición de negocio, la etiqueta del panel y el cálculo. Esta distinción permite estimar el trabajo técnico sin confundir una decisión semántica con una migración del esquema.
Presenta la decisión sobre la definición en cinco diapositivas
La revisión necesita el diccionario como respaldo, no el diccionario completo en pantalla. Para este ejemplo, utiliza estas cinco diapositivas:
- «Tres citas cerradas no son tres servicios prestados». Coloca la etiqueta discutida junto a la pregunta de operaciones.
- «Las mismas cuatro filas explican los dos totales». Muestra la tabla reducida y distingue completed, cancelled, no_show y booked sin resultado final.
- «Aprobar este significado de completada». Presenta la ficha del término, centrada en inclusión, excepciones y criterio temporal.
- «v2.0 cambia la comparación, no los hechos originales». Muestra el paso de tres a uno, el periodo de aplicación y los límites del recálculo histórico.
- «Aprobar la definición y asignar el cambio del informe». Identifica quién decide, quién valida la correspondencia y quién mantiene el informe; deja fuera la cuestión de ingresos.
Adjunta el diccionario completo y el registro del cambio para que el equipo pueda recuperar los detalles aprobados después. Si creas un borrador de diapositivas con estas notas, conserva los identificadores de campo exactamente como están escritos, mantén la palabra «ficticio» y no dejes que un título más corto borre la diferencia entre cerrada y completada. Convertir las notas en diapositivas no implica un análisis automático de bases de datos ni una sincronización de catálogos.
El resultado propuesto es concreto: aprobar completada como una cita cuyo servicio consta como prestado y tiene hora de finalización; conservar cerrada como una agrupación aparte; publicar la definición v2.0 con una ruptura histórica visible o con un recálculo etiquetado por separado. El equipo tiene ahora un acuerdo que se puede implementar, no solo un glosario que cada persona interpreta a su manera.
