En Horizonte, una persona puede tener varios contratos, un contrato puede producir varias facturas y un consentimiento puede cambiar con el tiempo. Si el modelo ignora esas diferencias, un informe puede duplicar importes y un asistente puede atribuir una autorización al propósito equivocado.
Conceptos Clave
Un modelo de datos representa una parte del negocio para poder comunicarla y trabajar con ella. Selecciona entidades, atributos, relaciones y restricciones relevantes. No reproduce toda la realidad: explicita las decisiones que importan para un uso. «Cliente» requiere acordar si significa persona, organización, cuenta comercial u otra entidad.
La cardinalidad indica cuántas ocurrencias pueden relacionarse. Un cliente puede tener muchos contratos; cada contrato del ejemplo pertenece a un cliente. Esa regla se debe validar con el negocio: si existen titulares conjuntos, el modelo necesita otra relación. Dibujar primero una clave foránea sin acordar la regla puede consolidar una suposición incorrecta.
La granularidad responde qué representa una fila. Una fila por factura y una fila por línea de factura no son intercambiables. Al combinar conjuntos con granularidades distintas, debemos conservar relaciones e importes correctamente. Un resultado SQL válido puede ser semánticamente equivocado.
Del Significado al Modelo Físico
El modelo conceptual permite conversar sobre entidades y reglas sin depender de una base de datos. El lógico precisa atributos, identificadores, relaciones y restricciones. El físico concreta tablas, tipos, índices y estructuras apropiadas para el motor elegido. Pasar de una vista a otra requiere decisiones; no consiste únicamente en traducir nombres.
Una clave técnica identifica un registro; una clave de negocio puede identificar una entidad en un contexto. Un número de cliente de dos sistemas distintos puede coincidir sin referirse a la misma persona. Por eso el mapeo entre identificadores debe mantener su origen. La deduplicación y las decisiones de identidad se profundizan en datos maestros.
El tiempo también se modela. Horizonte registra propósito, estado y vigencia del consentimiento. Un indicador booleano actual no permite explicar qué autorización existía en una fecha pasada. El modelo define qué historial se conserva y cómo se interpreta; la retención aplicable se acuerda con los responsables pertinentes.
Modelado y Semántica en Oracle
En Oracle AI Data Platform y Oracle Autonomous AI Lakehouse, esquemas, tablas y vistas permiten materializar modelos y productos de datos. El catálogo describe los activos, pero descubrir sus columnas no decide automáticamente la granularidad ni la definición de una métrica. El equipo mantiene esa correspondencia entre modelo de negocio y estructuras publicadas.
Una capa semántica expresa términos, medidas y relaciones para un consumo consistente. Una ontología hace explícitas entidades y relaciones de un dominio; puede aportar contexto para analítica y agentes. No es un sustituto del diseño físico. Tampoco garantiza que una inferencia de IA coincida con la definición aprobada por la organización.
En Oracle Analytics Cloud, usa Semantic Modeler para conectar las tablas con términos y medidas del negocio. Define las uniones físicas por sus claves, representa Cliente y Contrato mediante relaciones lógicas y cardinalidad y publica un modelo que los analistas puedan reutilizar. Oracle AI Data Platform y Oracle Autonomous AI Lakehouse aportan los datos preparados para ese consumo.
Para medir «clientes activos», selecciona los contratos vigentes en la fecha de corte y cuenta los identificadores de cliente distintos. C7 aporta un cliente aunque tenga varios contratos vigentes. El propietario aprueba la definición; el modelador configura la agregación de la medida y contrasta el resultado con casos conocidos. En Oracle Autonomous AI Database, Data Analysis permite organizar dimensiones, jerarquías y medidas en vistas analíticas. Así aplicas el modelado de DAMA: conservas el significado acordado desde las entidades hasta el indicador publicado.
Ejemplo Explicado
Horizonte tiene una factura de 100 unidades monetarias con dos líneas: 60 por servicio y 40 por instalación. Si el equipo une la cabecera con las líneas y suma el total de cabecera, obtiene 200. La consulta ejecuta correctamente la unión; el error está en sumar una medida de otra granularidad.
La solución es sumar los importes de línea, o agregar primero al nivel de factura antes de combinar con otros conjuntos. El steward documenta la métrica; el modelador confirma la relación; el equipo técnico implementa una vista coherente en el producto de Oracle Autonomous AI Lakehouse. El caso muestra por qué no basta con pedir al asistente «calcula ingresos» sin definir nivel, periodo y regla.
Errores Frecuentes
- Diseñar solo desde las columnas disponibles. Se omiten reglas del negocio que las columnas actuales quizá no representan.
- Usar el nombre como identificador inequívoco. Personas distintas pueden compartirlo y una persona puede cambiarlo.
- Creer que más contexto elimina toda ambigüedad. Los términos, relaciones e inferencias propuestas necesitan responsables y revisión.
Ejercicio de Decisión
Horizonte necesita responder si el cliente autorizó comunicaciones comerciales en la fecha de una campaña. Solo conserva una columna consentimiento_actual. ¿Basta para responder? ¿Qué debe representar el modelo?
Solución
No basta. El modelo necesita relacionar el sujeto con el propósito y su estado en el tiempo, incluyendo el evento o evidencia que respalda el cambio. Debe permitir interpretar la vigencia para la fecha consultada. La política define conservación y usos; almacenar más historial por defecto no sustituye esa decisión.