La ficha completa de fct_ventas: metadatos, una tabla visual con datos de ejemplo y el diccionario de columnas — tal como se ve en un catálogo de datos real.
Imagina que acabas de entrar al equipo de datos de una cadena de cafeterías. El primer pedido es simple: "necesitamos el total vendido este mes". Abres la base y encuentras una tabla llamada fct_ventas, sin ninguna nota al lado.
Ahí empiezan las dudas. ¿Una fila es un ticket completo, o un producto dentro de un ticket? Si se suma la columna cantidad sin saberlo, se podría estar contando "3 cafés en un mismo ticket" como si fueran tres ventas separadas. ¿Y precio? ¿es el precio de hoy, o el que se cobró ese día puntual? Si la cafetería subió precios la semana pasada, esa duda cambia el resultado del reporte.
Ese tipo de duda es exactamente lo que una ficha de documentación resuelve antes de que se convierta en un número equivocado en un reporte. El resto de esta página documenta fct_ventas paso a paso, hasta dejar cada una de esas preguntas sin ambigüedad.
Una tabla sin documentación es una caja negra: la próxima persona que la use (o tú mismo en seis meses) no sabe qué representa cada fila, si un valor puede venir vacío, o si esa columna ya está descontinuada. Documentar bien evita tres problemas típicos: preguntas repetidas en el chat del equipo, análisis hechos sobre datos mal entendidos, y miedo a tocar una tabla porque "nadie sabe para qué sirve esa columna".
Antes de listar columnas, toda ficha empieza con el contexto general de la tabla:
fct_ventasventas_rawcantidad da unidades vendidas, no cantidad de tickets. Si el grano fuera otro, esa misma suma significaría algo completamente distinto.
Mostrar filas reales (o simuladas) es lo que más rápido le da contexto a alguien nuevo. Así se vería fct_ventas con datos de muestra:
| id_venta | id_producto | id_cliente | cantidad | precio | fecha |
|---|---|---|---|---|---|
| 1001 | P-204 | C-88 | 2 | 15.50 | 2026-08-01 |
| 1002 | P-071 | C-88 | 1 | 42.00 | 2026-08-01 |
| 1003 | P-204 | C-15 | 3 | 15.50 | 2026-08-02 |
| 1004 | P-330 | C-42 | 1 | 9.90 | 2026-08-02 |
| 1005 | P-071 | C-15 | 2 | 42.00 | 2026-08-03 |
En ámbar, la clave primaria (id_venta). En verde, las claves foráneas que apuntan a las dimensiones (id_producto, id_cliente) — así se conecta esta tabla de hechos con el esquema en estrella que viste antes.
Después de la muestra visual, cada columna se describe una por una. Esto es lo que herramientas como dbt docs o un catálogo de datos generan automáticamente a partir de esta información:
| Columna | Tipo | Descripción | Ejemplo |
|---|---|---|---|
| id_ventaPK | integer | Identificador único de la línea de venta. No se repite nunca. | 1001 |
| id_productoFK | varchar | Referencia al producto vendido, apunta a dim_producto. |
P-204 |
| id_clienteFK | varchar | Referencia al cliente que compró, apunta a dim_cliente. Puede ser nulo si la venta fue sin registrar cliente. |
C-88 |
| cantidad | integer | Unidades del producto vendidas en esta línea. Siempre mayor a cero. | 2 |
| precio | decimal(10,2) | Precio unitario al momento de la venta, en la moneda local. No es el precio actual del producto — es el histórico de ese día. | 15.50 |
| fecha | date | Fecha en que se realizó la venta. Se usa para unir con dim_fecha. |
2026-08-01 |
La tabla de hechos guarda claves y medidas (números que se suman o promedian). Una dimensión, en cambio, guarda atributos descriptivos — texto que sirve para filtrar y agrupar. Compara el diccionario de dim_producto:
| Columna | Tipo | Descripción | Ejemplo |
|---|---|---|---|
| id_productoPK | varchar | Identificador único del producto. | P-204 |
| nombre | varchar | Nombre comercial del producto tal como aparece en el ticket. | Café molido 500g |
| categoria | varchar | Familia a la que pertenece, usada para agrupar reportes. | Almacén |
| activo | boolean | Si el producto todavía se vende o fue discontinuado. | true |
Nota: cuando un atributo como categoria se guarda en su propia tabla en vez de repetirse en cada producto, eso es justamente el paso de estrella a copo de nieve.
En un equipo real, esta ficha casi nunca se escribe a mano: se genera a partir del propio código de las tablas. Herramientas como dbt docs o SchemaSpy leen la base de datos (o los modelos de transformación) y arman esta documentación — incluyendo diagramas de relaciones — de forma automática.