7.7 Modelado de datos y capa semántica

Presentación y motivación

Un modelo de datos es una decisión sobre qué significan tus datos, tomada antes de decidir dónde viven los datos. Nombra las cosas que le importan a tu negocio, los atributos que las describen, y las relaciones entre ellas. El almacenamiento, los índices, los formatos de archivo, y los motores de consulta llegan todos después. Este orden importa porque el significado de tus datos sobrevive a toda tecnología que uses para contenerlos. Los almacenes se reemplazan, los formatos de tabla cambian, y los motores de consulta van y vienen, pero «cliente», «pedido», y «usuario activo» tienen que significar lo mismo a través de todos ellos, durante años.

Para un equipo pequeño, el modelado a menudo es implícito. Un ingeniero tiene todo el esquema en la cabeza, y una comprensión compartida de «ingresos» sobrevive porque solo hay tres personas que puedan discrepar. A la escala de las grandes organizaciones de desarrollo, las empresas, y las agencias gubernamentales, esa informalidad colapsa exactamente de la manera descrita en el capítulo 7.1 (estrategia y gobernanza de datos). Docenas de equipos construyen cientos de tablas, cada una con su propia idea de qué es una «sesión» o cuándo un usuario cuenta como «activo». Dos tableros muestran dos números distintos para la misma semana, y una reunión de liderazgo se convierte en una discusión sobre la consulta de quién es correcta en lugar de qué hacer a continuación. El mal modelado no se anuncia a sí mismo. Aparece meses después como trabajo de reconciliación, auditorías fallidas, y decisiones tomadas sobre cifras que nadie puede defender.

Este capítulo trata de hacer ese trabajo deliberadamente. Cubre los modelos conceptual, lógico y físico; el modelado entidad-relación; cuándo normalizar y cuándo desnormalizar; cómo el modelado difiere para cargas de trabajo transaccionales frente a analíticas; el modelado dimensional con hechos y dimensiones; y la capa semántica que contiene la única definición gobernada de cada métrica de negocio. El beneficio no es la elegancia por sí misma. Es que «usuario activo» e «ingresos» signifiquen una sola cosa en todas partes, para que tus equipos puedan confiar en los números y moverse más rápido gracias a eso.

Véase también: el capítulo 3.4 (arquitectura de datos y almacenamiento), el capítulo 7.3 (analítica e inteligencia de negocio), y el capítulo 11.5 (indicadores clave de rendimiento).

Principios fundamentales

Decide qué significan los datos antes de decidir dónde viven.
Modela en tres niveles: conceptual (negocio), lógico (estructura), físico (implementación).
Normaliza para proteger la corrección en los sistemas transaccionales; desnormaliza deliberadamente por velocidad analítica.
Ajusta el modelo a la carga de trabajo: las transacciones y la analítica tienen necesidades opuestas.
Cada métrica de negocio tiene exactamente una definición gobernada, y vive en la capa semántica.
Las dimensiones conformes permiten que equipos independientes unan y comparen datos con seguridad.
El grano es una decisión de diseño que tomas a propósito, no un accidente de una consulta.
Los modelos son activos vivos: nómbralos bien, documéntalos, y mantenlos evolucionables.

Recomendaciones

Modela en tres niveles, en orden

Trabaja del significado hacia afuera. Empieza con un modelo conceptual: las entidades que le importan a tu negocio y cómo se relacionan, escrito en lenguaje claro que un experto de dominio pueda verificar. «Un cliente hace muchos pedidos; un pedido contiene muchas líneas de artículo; cada línea de artículo se refiere a un producto». Sin claves, sin tipos, sin tablas todavía. Luego construye un modelo lógico que añade estructura: atributos, claves primarias y foráneas, cardinalidades, y restricciones, todavía independiente de cualquier base de datos específica. El modelado entidad-relación es la notación estándar aquí, y un diagrama entidad-relación es el artefacto que revisas tanto con ingenieros como con partes interesadas de negocio. Solo entonces produce el modelo físico: las tablas reales, columnas, tipos de datos, índices, particiones, y disposición de almacenamiento para tu motor elegido. Saltar directamente al diseño físico es el error de modelado más común, porque incrusta las elecciones tecnológicas de hoy en decisiones que deberían sobrevivirlas.

Normaliza los sistemas transaccionales, desnormaliza los analíticos a propósito

Para los sistemas que registran transacciones, favorece la normalización de bases de datos. Las formas normales eliminan la redundancia para que cada hecho se almacene una vez, lo cual previene anomalías de actualización y mantiene las escrituras correctas cuando muchos usuarios cambian datos concurrentemente. Este es el valor predeterminado correcto para el procesamiento de transacciones en línea (OLTP), donde la corrección bajo escrituras concurrentes importa más que la velocidad de cualquier consulta analítica individual. Los sistemas analíticos tienen prioridades opuestas. Son intensivos en lectura, escanean y agregan rangos enormes, y unir docenas de tablas normalizadas en el momento de la consulta es lento y difícil de razonar. Ahí desnormalizas a propósito, colapsando atributos relacionados juntos para que las consultas sean más simples y rápidas. La disciplina es desnormalizar deliberadamente, con una razón documentada, en lugar de dejar que la redundancia se cuele por accidente. El capítulo 3.4 (arquitectura de datos y almacenamiento) cubre los motores que hacen que cada patrón rinda.

Usa el modelado dimensional para la analítica

Para las cargas de trabajo analíticas, adopta el modelado dimensional, el enfoque popularizado por Ralph Kimball. Divides el mundo en hechos y dimensiones. Una tabla de hechos contiene las mediciones de un proceso de negocio: el monto de una venta, la duración de una llamada, la cantidad enviada. Las tablas de dimensiones contienen el contexto descriptivo por el que filtras y agrupas: el cliente, el producto, la tienda, la fecha. Organiza una tabla de hechos rodeada de sus dimensiones y tienes un esquema de estrella, que es fácil de entender para los analistas y rápido de consultar para los motores. Normaliza esas dimensiones en subtablas y obtienes un esquema de copo de nieve, que ahorra algo de almacenamiento al costo de más uniones y más complejidad; prefiere la estrella a menos que tengas una razón concreta. Para entornos muy grandes y altamente regulados donde la auditabilidad y el rastreo de fuentes dominan, un enfoque de data vault modela concentradores, enlaces, y satélites para capturar el historial y el linaje agresivamente, al costo de más tablas y una curva de aprendizaje más pronunciada. La mayoría de los equipos deberían empezar con estrellas al estilo Kimball y recurrir al data vault solo cuando los requisitos de auditoría lo justifiquen.

Fija el grano y maneja las dimensiones cambiantes explícitamente

Antes de añadir una sola columna a una tabla de hechos, declara su grano: exactamente qué representa una fila. «Una fila por línea de artículo de pedido». «Una fila por usuario por día». El grano es el fundamento de un modelo correcto, porque cada medida y cada dimensión o encajan en ese grano o no pertenecen a la tabla. Mezclar granos es cómo obtienes ingresos contados dos veces. Luego decide cómo cambian las dimensiones con el tiempo. Un cliente se muda a una nueva ciudad; ¿sobrescribes el valor antiguo, mantienes un historial completo, o rastreas solo el valor actual y el anterior? Estos son los patrones estándar de dimensión de cambio lento, y elegir mal significa que tus informes históricos reescriben silenciosamente el pasado. Decide el grano y la estrategia de cambio por adelantado, escríbelos en la documentación del modelo, y mantén la línea en la revisión.

Construye una capa semántica como la única definición de cada métrica

Esta es la recomendación que paga por todo el capítulo. Una capa semántica se sitúa entre tus tablas físicas y cada herramienta que las consume, y contiene la única definición gobernada de cada métrica de negocio. «Usuario activo» se define una vez, como código, con su lógica exacta: qué eventos cuentan, sobre qué ventana, excluyendo qué cuentas internas. «Ingresos» se define una vez, incluyendo cómo se manejan los reembolsos, los descuentos, y la conversión de moneda. Cada tablero, cuaderno, informe, y trabajo de ETL inverso lee esa definición en lugar de reimplementarla en una consulta a medida. Cuando la definición cambia, cambia en un solo lugar y cada consumidor se actualiza junto con ella. Este es el mecanismo que hace que las definiciones de métricas gobernadas sean reales en lugar de aspiracionales, y es la implementación directa de lo que pide el capítulo 11.5 (indicadores clave de rendimiento). Trata las definiciones de métricas como código versionado con dueños, revisión, y pruebas, exactamente como el capítulo 7.1 te pide tratar los datos como un producto.

Establece convenciones, nomenclatura y documentación

La consistencia es una función. Adopta convenciones de nomenclatura y hazlas cumplir: una convención para nombres de tablas, una convención para claves, un estándar para columnas de fecha, una regla para cómo marcas un hecho frente a una dimensión. Decide una vez si usas nombres de entidad singulares o plurales y nunca los mezcles. Documenta cada modelo donde la gente que lo usa vaya a mirar: el significado de cada tabla, el grano de cada hecho, la definición de cada métrica, y el dueño de cada uno. Una buena nomenclatura y documentación son lo que permite que un nuevo analista se autoatienda en lugar de interrumpir al equipo, y son lo que permite que un auditor rastree un número desde una presentación para la junta hasta su fuente sin un recorrido guiado.

Mantén los modelos evolucionables

Tu modelo cambiará, así que diseña para el cambio. Añade columnas en lugar de reutilizar las existentes. Usa claves sustitutas para que un cambio en la clave natural de un sistema fuente no se propague por tu almacén. Versiona las definiciones de métricas y decláralas obsoletas con aviso en lugar de alterarlas silenciosamente bajo tableros en ejecución. Mantén las transformaciones en control de versiones, probadas, y revisadas, para que un cambio en lo que significa «usuario activo» sea una solicitud de extracción con un diff y un aprobador, no una edición silenciosa en una herramienta de BI. Un modelo que no puedes evolucionar con seguridad se convierte en un modelo que la gente rodea, y las definiciones en la sombra son cómo muere la fuente única de verdad.

Ventajas y desventajas

Enfoque	Ventajas	Desventajas	Mejor ajuste
Normalizado (3FN)	Escrituras correctas, sin redundancia, flexible	Uniones analíticas lentas, consultas complejas	OLTP y sistemas operacionales
Esquema de estrella (Kimball)	Rápido, intuitivo, amigable para analistas	Algo de redundancia, ETL que mantener	La mayoría de la analítica y BI
Esquema de copo de nieve	Menos almacenamiento, dimensiones más limpias	Más uniones, más complejidad	Dimensiones grandes y estrictamente gobernadas
Data vault	Historial completo, auditable, cargas ágiles	Muchas tablas, curva de aprendizaje pronunciada	Altamente regulado, intensivo en auditoría
Capa semántica sobre modelos	Una definición en todas partes, agnóstica de herramienta	Construcción por adelantado, necesita propiedad	Organizaciones multiequipo, multiherramienta

La tensión central es la velocidad de una única consulta frente a la corrección y flexibilidad a través de todo el patrimonio. La normalización protege la corrección y la paga en complejidad de consulta; los modelos dimensionales compran velocidad de consulta y claridad y la pagan con ETL y algo de redundancia gestionada. No hay un ganador universal, por eso ajustas el modelo a la carga de trabajo en lugar de elegir un favorito. La capa semántica resuelve la segunda tensión, entre muchos equipos y muchas herramientas, al hacer la definición de la métrica independiente de cualquiera de ellas. El error es tratar estos como bandos ideológicos. Una organización saludable ejecuta sistemas OLTP normalizados, modelos analíticos dimensionales alimentados por ellos, y una capa semántica encima, cada uno haciendo el trabajo para el que es bueno.

Preguntas para discutir con tu equipo

Cuando dos tableros muestran números distintos para la misma métrica, ¿qué definición gana, y dónde vive físicamente esa definición? Esta pregunta expone si realmente tienes una fuente única de verdad o solo crees que la tienes. En la mayoría de los equipos grandes la respuesta honesta es que «usuario activo» se redefine en una docena de consultas distintas, y el ganador es quien discuta más fuerte en la reunión. Trae evidencia real: elige una métrica, encuentra cada lugar donde se calcula, y compara la lógica línea por línea. Casi con certeza encontrarás desacuerdos silenciosos sobre ventanas, exclusiones, y casos límite. La respuesta debería impulsar una decisión de construir una capa semántica donde cada métrica se defina una vez, como código revisado, así la pregunta deja de ser sobre personas y empieza a ser sobre un artefacto versionado. Hasta que esa definición tenga un único hogar físico, cada reconciliación es temporal.
¿Cuál es el grano de tu tabla de hechos más importante, y puede todo el mundo en la sala expresarlo de la misma manera? El grano es el fundamento silencioso al que se remontan la mayoría de los fallos de modelado. Si la mitad del equipo dice «una fila por pedido» y la otra mitad dice «una fila por línea de artículo», tienes un error de conteo doble esperando aparecer en un informe de ingresos. Trae la tabla real y pide a cada persona que describa una fila en una sola oración. El desacuerdo aquí no es un problema de comunicación que suavizar; es un defecto de diseño que arreglar antes de que más medidas se amontonen encima. La respuesta debería escribirse en la documentación del modelo y aplicarse en la revisión, porque una vez que los analistas construyen consultas sobre un grano ambiguo, la ambigüedad se propaga más rápido de lo que puedes corregirla.
¿Cómo absorberá este modelo el cambio, y qué pasa con los informes del año pasado cuando una definición cambia? Cada modelo enfrenta sistemas fuente cambiantes, reglas de negocio cambiantes, y definiciones de métricas cambiantes, así que la pregunta real es si el cambio es una solicitud de extracción controlada o una edición silenciosa que reescribe el historial. Trae un ejemplo reciente: una métrica cuya definición cambió, o una clave fuente que fue renombrada, y rastrea qué pasó con los tableros existentes. Si una dimensión de cambio lento se manejó sobrescribiendo, tus informes históricos pueden haber cambiado silenciosamente sus valores pasados, lo cual es un problema serio para cualquiera que haga análisis de tendencias o reporte regulado. La respuesta debería empujarte hacia claves sustitutas, definiciones de métricas versionadas, estrategias de cambio explícitas, y transformaciones mantenidas en control de versiones con revisión. Un modelo que nadie puede cambiar con seguridad se convierte en un modelo que la gente abandona.
¿Qué dimensiones deben significar lo mismo en todos los equipos, y quién es responsable de ser dueño de cada una? Las dimensiones conformes son lo que permite que marketing, finanzas y operaciones unan sus datos y obtengan respuestas comparables, pero solo cuando «cliente», «producto», «región», y «fecha» llevan una definición acordada en lugar de una copia privada por equipo. El impulso en competencia es la autonomía: cada equipo quiere modelar su propio mundo a su propio ritmo, y forzar una dimensión compartida los ralentiza a corto plazo mientras se paga a sí misma a través del patrimonio. Trae las dos o tres dimensiones que aparecen en más informes entre equipos, enumera cada versión de cada una que existe hoy, y observa cuánto divergen realmente sus claves y atributos. Nombra un dueño para cada dimensión conforme, porque una dimensión compartida sin dueño deriva de vuelta a copias privadas en un trimestre. En entornos empresariales y gubernamentales, donde una cifra de un departamento se compara con otra en público, una dimensión no conforme es la diferencia entre una comparación honesta y una falsedad accidental, así que decide temprano qué dimensiones se gobiernan centralmente y cuáles permanecen locales.
¿Dónde se sitúa la frontera entre tus sistemas transaccionales normalizados y tus modelos analíticos desnormalizados, y es cada desnormalización una decisión deliberada? Ajustar el modelo a la carga de trabajo es la disciplina central, sin embargo la frontera es exactamente donde se difumina: un analista desnormaliza una tabla del almacén por velocidad, un ingeniero normaliza una tabla de reporte por hábito, y nadie escribió a qué lado pertenece cada elección. La tensión es la velocidad de una única consulta frente a la corrección y flexibilidad a través de todo, y personas razonables caen de manera distinta según si son dueñas de las escrituras o de las lecturas. Trae tu consulta analítica más lenta y tu tabla transaccional más disputada, y pregunta para cada columna redundante si su redundancia se eligió con una razón documentada o se coló por accidente. La meta es una regla escrita para cuándo se permite la desnormalización y quién la aprueba, no un concurso de pureza. Para organizaciones grandes o reguladas, esta frontera también decide dónde se duplican los datos personales, así que una desnormalización no documentada es tanto una cuestión de rendimiento como una exposición de gobernanza de datos que alguien eventualmente tendrá que explicarle a un auditor.
¿Deberías construir o comprar la capa semántica, y quién es responsable de mantener actualizada cada definición de métrica una vez que existe? Una capa semántica solo entrega una fuente única de verdad cuando tiene dueño y se mantiene, así que la elección de la herramienta importa menos que la respuesta a quién revisa un cambio en lo que significa «ingresos» y quién responde cuando una definición se vuelve obsoleta. Las consideraciones en competencia son reales: construir te da control y se ajusta a tu pila pero añade una carga de ingeniería, mientras que comprar una herramienta de métricas es más rápido pero arriesga la dependencia de un proveedor único y un lenguaje de definición que no controlas por completo. Trae tu puñado de métricas de mayor riesgo, las herramientas que las consumen hoy, y una lectura honesta de si alguien actualmente es dueño de esas definiciones o simplemente existen. Decide por adelantado si las definiciones viven como código versionado con dueños nombrados y pruebas, porque una capa semántica que nadie mantiene se pudre en las mismas definiciones dispersas que se suponía que reemplazaría. En el reporte empresarial y gubernamental, donde una métrica en un tablero público debe poder rastrearse hasta una definición documentada y revisada, esa propiedad y la capacidad de probar el linaje de un número es lo que convierte la capa semántica de una conveniencia en un control auditable.

Perspectiva sectorial

Startup. El modelado puede esperar, pero las definiciones no. Con dos ingenieros y sin fondos para construir un almacén, pon una pequeña capa semántica en tu herramienta de transformación y define las dos o tres métricas que tu junta realmente vigila, «usuario activo» e «ingresos», una vez como código probado. Salta el data vault y los esquemas dimensionales elaborados; una estrella delgada y un puñado de definiciones gobernadas te compran números consistentes sin ralentizar la entrega. El beneficio es que la preparación de la junta deja de ser una discusión sobre la consulta de quién es correcta.

Pequeña empresa. No tienes un modelador de datos ni presupuesto para una plataforma de métricas, así que apóyate en las definiciones incorporadas en las herramientas que ya operas y escribe las pocas que importan en un documento compartido que todos lean. Favorece comprar analítica incorporada en tu software existente sobre levantar un almacén que no puedes dotar de personal. Donde sí modeles, mantenlo simple y nombra las cosas de manera consistente, porque la persona que lo mantenga el año próximo puede ser quien no recuerde por qué «cliente» significaba dos cosas. La consistencia es más barata que la reconciliación.

Empresa. El problema es que muchos equipos y muchas herramientas derivan hacia definiciones privadas, así que invierte en dimensiones conformes, una capa semántica gobernada única, y definiciones de métricas mantenidas como código versionado con dueños y revisión. Estandariza la nomenclatura, las declaraciones de grano, y las estrategias de dimensión de cambio lento a través del patrimonio para que un número en una herramienta coincida con el mismo número en otra. Trata la capa semántica como un producto con una hoja de ruta y un equipo dueño, y mide cuánto tiempo de reconciliación elimina. El retorno son números confiables a través del negocio y auditorías que rastrean limpiamente desde una presentación para la junta hasta la fuente.

Gobierno. La transparencia y la comparabilidad entre agencias moldean el trabajo: datos de referencia canónicos para geografía y demografía, definiciones gobernadas de indicadores centrales, y metodología publicada con lanzamientos versionados para que el público pueda rastrear cualquier cifra hasta una definición documentada. Las reglas de contratación pública pueden exigir que tus modelos y definiciones permanezcan portables y neutrales respecto al proveedor, así que evita una capa semántica atada a una herramienta propietaria única. Mantén a las agencias individuales libres para modelar sus datos operacionales mientras se conforman a las dimensiones compartidas para cualquier cosa reportada a nivel nacional. Un indicador publicado que no puede rastrearse hasta una definición versionada es un fallo de rendición de cuentas tanto como uno de datos.

Ejemplos

Startup. Una empresa en Serie A tenía tres definiciones de «usuario activo» viviendo en tres lugares: la herramienta de analítica de producto, la hoja de cálculo de finanzas, y la presentación para inversores. Los números nunca coincidían, y cada preparación de la junta se convertía en una carrera. Dos ingenieros introdujeron una pequeña capa semántica en su herramienta de transformación, definiendo «usuario activo» e «ingresos recurrentes mensuales» una vez como código probado, con las ventanas y exclusiones exactas escritas. Cada tablero ahora lee esas definiciones. La discusión de preparación de la junta desapareció, e incorporar a un nuevo analista pasó de una semana de conocimiento tribal a leer un modelo documentado. Esto se conecta directamente con la disciplina descrita en el capítulo 7.4 (analítica de producto y experimentación), donde una definición estable de «activo» es lo que hace comparables los resultados de los experimentos.

Empresa. Un minorista global operaba cinco herramientas de inteligencia de negocio a través de marketing, finanzas, cadena de suministro, mercadeo, y tiendas, y cada una había reinventado el «margen bruto» ligeramente distinto. Construyeron una capa semántica única sobre un almacén al estilo Kimball con dimensiones conformes, para que «producto», «tienda», y «fecha» significaran lo mismo a través de cada tabla de hechos y cada herramienta. Cada métrica se definió una vez y se consumió en todas partes. Las reuniones de reconciliación que solían consumir días por trimestre en su mayoría desaparecieron, y cuando finanzas cambió cómo las devoluciones afectaban el margen, el cambio se propagó a las cinco herramientas a la vez. Las dimensiones conformes fueron lo que permitió que equipos independientes unieran sus datos con confianza en lugar de sospecha.

Gobierno. Un gobierno nacional necesitaba reporte comparable a través de agencias de salud, trabajo, y educación, cada una de las cuales históricamente había definido «hogar», «región», y «empleo» a su manera. Un organismo entre agencias estableció datos de referencia compartidos y definiciones estándar: tablas de dimensiones canónicas para geografía y demografía, y definiciones gobernadas de indicadores centrales, publicadas con metodología y lanzamientos versionados. Las agencias individuales modelan sus propios datos operacionales pero se conforman a las dimensiones y definiciones compartidas para cualquier cosa reportada a nivel nacional. El resultado es que una cifra de una agencia puede compararse honestamente con otra, y el público puede rastrear cualquier indicador publicado hasta una definición documentada, apoyando las obligaciones de transparencia cubiertas en el capítulo 7.1.

Caso de negocio: motivaciones, ROI y TCO

El retorno de un buen modelado y una capa semántica es principalmente tiempo recuperado y error evitado. En muchas organizaciones, los analistas pasan la mayoría de su tiempo encontrando datos, reconciliando números contradictorios, y reconstruyendo definiciones que otras personas ya escribieron. Una única definición gobernada de cada métrica convierte ese trabajo repetido en una inversión única. También elimina toda una categoría de fallo costoso: el número equivocado en una presentación para la junta, la cifra mal reportada que dispara un hallazgo de auditoría, el proyecto de reconciliación de un trimestre entero que existe solo porque dos equipos definieron «ingresos» de forma distinta. Cuando la definición vive en un único lugar revisado, esos fallos en gran medida dejan de ocurrir.

El costo es real y vale la pena nombrarlo. Inviertes por adelantado en el modelado conceptual y lógico, en construir y poblar la capa semántica, y en la propiedad continua que mantiene las definiciones actualizadas. El costo total de propiedad (TCO) incluye las herramientas, el tiempo de modelado e ingeniería analítica, y la gobernanza para evitar que el modelo derive. Pésalo contra el costo de no hacerlo, que es mayor pero oculto: aparece como canales duplicados, analistas como motores humanos de reconciliación, y ejecutivos tomando decisiones confiadas sobre cifras que nadie puede defender. Presenta el caso al liderazgo en sus términos. Una definición confiable de cada métrica es lo que les permite comparar a través del negocio, confiar en los tableros, y responder a los reguladores sin un simulacro de incendio. Empieza donde el dolor de reconciliación es peor, define esas pocas métricas una vez, y deja que el tiempo recuperado financie el resto.

Antipatrones y trampas

Saltar directamente a las tablas físicas, incrustando la tecnología de hoy en decisiones que deberían sobrevivirla.
Definir la misma métrica independientemente en cada tablero, así que ningún par de números coincide.
Dejar el grano sin declarar, luego descubrir medidas contadas dos veces en un informe de ingresos.
Desnormalizar tablas analíticas por accidente en lugar de por decisión documentada.
Normalizar un almacén analítico hasta que cada consulta es una unión de doce tablas que nadie entiende.
Manejar las dimensiones de cambio lento sobrescribiendo, así los informes históricos reescriben silenciosamente el pasado.
Usar claves naturales en todas partes, así un cambio de clave del sistema fuente se propaga por todo el almacén.
Construir una capa semántica sin dueño, así las definiciones derivan y la confianza se erosiona.
Tratar el modelo como terminado al lanzamiento en lugar de un activo vivo que debe permanecer evolucionable.

Modelo de madurez

Nivel 1, Iniciar: El modelado es implícito y reactivo. Las tablas se diseñan primero-físico por quien las necesite. Las métricas se redefinen en cada informe, y los números entran en conflicto rutinariamente. El grano no está documentado, y nadie es dueño de las definiciones.
Nivel 2, Desarrollar: Algunas tablas analíticas siguen un patrón dimensional, y unas pocas métricas clave tienen definiciones escritas, pero viven en una wiki y no se aplican. Las convenciones de nomenclatura existen en papel. La práctica varía equipo por equipo, y la reconciliación sigue siendo frecuente y manual.
Nivel 3, Estandarizar: Los modelos conceptual, lógico, y físico son distintos y se revisan. Una capa semántica define las métricas centrales una vez, como código versionado con dueños. Las dimensiones conformes permiten a los equipos unirse con seguridad. Las estrategias de grano y dimensión de cambio lento están documentadas y se aplican en revisión en toda la organización.
Nivel 4, Gestionar: El patrimonio de modelos se mide contra líneas base. Rastreas la cobertura de definición de métricas (el porcentaje de métricas reportadas servidas por la capa semántica), el conteo de definiciones duplicadas o en la sombra todavía en uso, las horas de reconciliación gastadas por trimestre, y la tasa de defectos de grano y linaje atrapados en revisión frente a en producción. Los cambios de definición fluyen a través de solicitudes de extracción revisadas con pruebas, y la frescura, las tasas de aprobación de pruebas, y la deriva se vigilan en tableros. Cuando una métrica diverge o una dimensión deja de conformarse, la medición lo expone antes de que lo haga una reunión de la junta.
Nivel 5, Orquestar: Cada métrica importante tiene una definición gobernada consumida por todas las herramientas y equipos, y la capa semántica está integrada con la analítica, la experimentación, y el reporte regulado. Los modelos son evolucionables por diseño y se refinan continuamente; las definiciones son confiables en toda la organización; el trabajo de reconciliación en gran medida ha desaparecido. La organización rutinariamente declara obsoletas, reajusta el alcance, y conforma nuevas dimensiones a medida que cambia el negocio, reequilibrando el patrimonio de modelos como un activo adaptativo.

Ideas para el debate

Elige tus tres métricas más importantes. ¿Cuántas definiciones distintas de cada una existen a través de tus herramientas hoy, y qué se necesitaría para colapsarlas a una?
¿Dónde ha causado un grano no declarado un error de reporte real, y cuánto tiempo tomó notarlo?
¿Cuáles de tus dimensiones deberían conformarse entre equipos primero, y quién es su dueño?
¿Tus definiciones de métricas están en control de versiones con revisión, o son editables silenciosamente dentro de una herramienta de BI?
¿Cuándo reescribió por última vez una dimensión de cambio lento tu historial sin que nadie lo notara, y cómo lo atraparías la próxima vez?
Si reemplazaras tu motor de almacén mañana, ¿cuánto del significado de tu modelo sobreviviría el cambio?

Puntos clave

El modelado de datos es decidir qué significan los datos, y ese significado sobrevive a toda tecnología de almacenamiento que elijas.
Modela en tres niveles en orden: conceptual, luego lógico, luego físico.
Normaliza los sistemas transaccionales por corrección; desnormaliza los analíticos deliberadamente por velocidad.
Usa el modelado dimensional con hechos, dimensiones, y un grano declarado para la analítica.
Construye una capa semántica única para que cada métrica de negocio tenga una única definición gobernada en todas partes.
Las dimensiones conformes permiten que equipos independientes unan y comparen sus datos con confianza.
Nombra bien, documenta, usa claves sustitutas, y versiona las definiciones para que el modelo permanezca evolucionable.

Referencias y lecturas adicionales

Ralph Kimball y Margy Ross, The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling.
Bill Inmon, Building the Data Warehouse.
Dan Linstedt y Michael Olschimke, Building a Scalable Data Warehouse with Data Vault 2.0.
Peter Chen, «The Entity-Relationship Model: Toward a Unified View of Data», ACM Transactions on Database Systems.
E. F. Codd, «A Relational Model of Data for Large Shared Data Banks», Communications of the ACM.
C. J. Date, An Introduction to Database Systems.
Lars Rönnbäck y colegas, escritos sobre el modelado de anclas.
DAMA International, DAMA-DMBOK: Data Management Body of Knowledge.