{"id":6748,"date":"2026-07-12T02:05:45","date_gmt":"2026-07-12T10:05:45","guid":{"rendered":"https:\/\/www.gudusoft.com\/data-lineage-examples\/"},"modified":"2026-07-13T19:03:45","modified_gmt":"2026-07-14T03:03:45","slug":"data-lineage-examples","status":"publish","type":"page","link":"https:\/\/www.gudusoft.com\/es\/ejemplos-de-linaje-de-datos\/","title":{"rendered":"Ejemplos de linaje de datos: 6 escenarios reales con SQL y diagramas"},"content":{"rendered":"

A ejemplo de linaje de datos<\/strong> Muestra, para una parte concreta de SQL, qu\u00e9 tablas y columnas de origen alimentan qu\u00e9 columnas de salida, y a trav\u00e9s de qu\u00e9 transformaciones pasan los datos en el proceso. Los seis ejemplos resueltos a continuaci\u00f3n cubren las situaciones con las que se encuentran realmente los ingenieros de datos: una simple INSERTAR-SELECCIONAR<\/code>Se incluyen ejemplos como una transformaci\u00f3n multi-CTE, una cadena de vistas, un procedimiento almacenado con SQL din\u00e1mico, una cadena de modelos dbt y un flujo ETL entre bases de datos. Cada ejemplo proporciona el c\u00f3digo SQL y describe con precisi\u00f3n el aspecto del grafo de linaje.<\/p>\n\n\n\n

6<\/b>Ejemplos pr\u00e1cticos, cada uno con SQL real.<\/span><\/div>
39<\/b>Dialectos SQL, cada uno con un analizador dedicado.<\/span><\/div>
Nivel de columna<\/b>granularidad, no solo a nivel de tabla<\/span><\/div>
Directo + indirecto<\/b>bordes, ambos rastreados<\/span><\/div><\/div>\n\n\n\n
\n\n

Todos los ejemplos de esta p\u00e1gina son reproducibles:<\/strong> pegue el SQL en el Visualizador de linaje SQLFlow gratuito<\/a> y obtendr\u00e1 el diagrama interactivo que se describe a continuaci\u00f3n.<\/p>\n\n<\/div><\/div>\n\n\n\n

C\u00f3mo leer estos ejemplos<\/h2>\n\n\n\n

Cada grafo de linaje contiene dos tipos de aristas.<\/strong> A directo<\/strong> El borde significa que los datos fluyen f\u00edsicamente desde una columna de origen a una columna de destino, posiblemente a trav\u00e9s de una funci\u00f3n o agregaci\u00f3n. indirecto<\/strong> borde significa que una columna da forma al resultado sin aterrizar en \u00e9l: columnas utilizadas en D\u00d3NDE<\/code>, UNIRSE<\/code>, y AGRUPACI\u00d3N POR<\/code> cl\u00e1usulas. Ignorar los bordes indirectos es la forma en que el an\u00e1lisis de impacto falla, porque eliminar una columna de filtro rompe un informe con la misma seguridad que eliminar una seleccionada. Si estos t\u00e9rminos son nuevos, comience con \u00bfQu\u00e9 es el linaje de datos?<\/a> y C\u00f3mo funciona el linaje a nivel de columna<\/a>, luego regresa.<\/p>\n\n\n\n

Ejemplo 1: un ejemplo sencillo de linaje de datos INSERT-SELECT<\/h2>\n\n\n\n

El punto de partida para cualquier debate sobre linajes: una declaraci\u00f3n que escriba datos agregados en una tabla resumen.<\/p>\n\n\n\n

INSERTAR EN sales_summary (region, total_amount) SELECCIONAR c.region, SUMA(o.amount) DE orders o UNIR clientes c EN o.customer_id = c.id DONDE o.status = 'completed' AGRUPAR POR c.region;<\/code><\/pre>\n\n\n\n
El gr\u00e1fico de linaje tiene tres tablas (pedidos<\/code>, clientes<\/code>, resumen_de_ventas<\/code>) y estos bordes a nivel de columna:<\/p>\n\n\n\n
\n
Columna objetivo<\/th>Columna de origen<\/th>Tipo de borde<\/th>A trav\u00e9s de<\/th><\/tr><\/thead>
resumen_de_ventas.regi\u00f3n<\/code><\/td>clientes.regi\u00f3n<\/code><\/td>Directo<\/td>copia sin formato<\/td><\/tr>\n
resumen_de_ventas.importe_total<\/code><\/td>pedidos.cantidad<\/code><\/td>Directo<\/td>SUMA()<\/code><\/td><\/tr>\n
resumen_de_ventas.*<\/code><\/td>estado de los pedidos<\/code><\/td>Indirecto<\/td>D\u00d3NDE<\/code> filtrar<\/td><\/tr>\n
resumen_de_ventas.*<\/code><\/td>pedidos.id_cliente<\/code>, clientes.id<\/code><\/td>Indirecto<\/td>UNIRSE<\/code> condici\u00f3n<\/td><\/tr>\n<\/tbody><\/table><\/figure>\n\n\n\n
Observa lo que el gr\u00e1fico ya te muestra y que una vista a nivel de tabla no te mostrar\u00eda: clientes.email<\/code> y todas las dem\u00e1s columnas intactas no juegan ning\u00fan papel aqu\u00ed, y estado de los pedidos<\/code> Importa aunque nunca aparezca en el resultado. Muchas herramientas de linaje omiten por completo ese \u00faltimo aspecto; SQLFlow modela el linaje directo e indirecto como tipos de relaci\u00f3n separados y configurables.<\/p>\n\n\n\n
Ejemplo 2: transformaci\u00f3n multi-CTE<\/h2>\n\n\n\n
Es donde empiezan a situarse los diagramas de linaje dibujados a mano, porque cada CTE es una relaci\u00f3n temporal por la que debe pasar el gr\u00e1fico sin perder de vista las fuentes originales.<\/p>\n\n\n\n
WITH daily AS ( SELECT order_date, customer_id, SUM(amount) AS day_total FROM orders GROUP BY order_date, customer_id ), ranked AS ( SELECT customer_id, day_total, ROW_NUMBER() OVER (PARTITION BY customer_id ORDER BY day_total DESC) AS rn FROM daily ) SELECT customer_id, day_total AS best_day_revenue FROM ranked WHERE rn = 1;<\/code><\/pre>\n\n\n\n
El gr\u00e1fico de linaje se muestra a diario<\/code> y clasificado<\/code> como nodos intermedios, por lo que la ruta completa de la columna interesante es: pedidos.cantidad<\/code> \u2192 SUMA()<\/code> \u2192 total_diario<\/code> \u2192 clasificado.total_d\u00eda<\/code> \u2192 mejores_ingresos_del_d\u00eda<\/code>La funci\u00f3n de ventana crea una cadena m\u00e1s sutil: rn<\/code> se calcula a partir de ID del cliente<\/code> (partici\u00f3n) y total_del_d\u00eda<\/code> (ordenar), y luego DONDE rn = 1<\/code> marcas rn<\/code> una entrada indirecta a cada columna de salida. Entonces pedidos.cantidad<\/code> influencias mejores_ingresos_del_d\u00eda<\/code> De dos maneras: directamente a trav\u00e9s de la suma e indirectamente a trav\u00e9s de la clasificaci\u00f3n que decide qu\u00e9 fila se conserva. Un solucionador que solo compara patrones de nombres de columna no puede ver esa segunda v\u00eda.<\/p>\n\n\n\n
Ejemplo 3: una cadena de opiniones<\/h2>\n\n\n\n
Las vistas se acumulan. En un almac\u00e9n de datos maduro, un informe suele estar a tres o cuatro definiciones de vista de distancia de las tablas f\u00edsicas, y la pregunta "\u00bfde d\u00f3nde viene realmente este n\u00famero?" requiere recorrer toda la cadena.<\/p>\n\n\n\n
CREATE VIEW v_active_customers AS SELECT id, name, email FROM customers WHERE status = 'active'; CREATE VIEW v_customer_revenue AS SELECT a.id, a.name, SUM(o.amount) AS revenue FROM v_active_customers a JOIN orders o ON o.customer_id = a.id GROUP BY a.id, a.name;<\/code><\/pre>\n\n\n\n
El gr\u00e1fico muestra v_ingresos_clientes.ingresos<\/code> trazando a trav\u00e9s del l\u00edmite de la vista de regreso a pedidos.cantidad<\/code>, con estado de los clientes<\/code> adjunta como una arista indirecta heredada del filtro de la primera vista. Tambi\u00e9n expone algo \u00fatil en la otra direcci\u00f3n: v_clientes_activos.correo electr\u00f3nico<\/code> es seleccionada por la primera vista pero no es consumida por nada posterior. Las columnas muertas como esta son exactamente lo que se desea encontrar antes de una limpieza o migraci\u00f3n, y son invisibles a nivel de tabla. Cuando las definiciones de vista utilizan SELECCIONAR *<\/code>SQLFlow expande el asterisco contra el esquema para que cada columna heredada siga resolvi\u00e9ndose a su origen f\u00edsico.<\/p>\n\n\n\n
\n\n
Ejemplo 4: procedimiento almacenado con SQL din\u00e1mico<\/h2>\n\n\n\n
Este es el ejemplo que distingue a las herramientas de linaje, ya que el nombre de la tabla de destino ni siquiera existe como texto literal en el c\u00f3digo. Aqu\u00ed hay un procedimiento de SQL Server que crea una instant\u00e1nea mensual a trav\u00e9s de una tabla temporal y una tabla ensamblada din\u00e1micamente. INSERTAR<\/code>:<\/p>\n\n\n\n
CREATE PROCEDURE dbo.load_monthly_snapshot @month VARCHAR(7) AS BEGIN SELECT o.customer_id, SUM(o.amount) AS month_total INTO #monthly FROM dbo.orders o WHERE CONVERT(VARCHAR(7), o.order_date, 126) = @month GROUP BY o.customer_id; DECLARE @sql NVARCHAR(MAX) = N'INSERT INTO dbo.snapshot_monthly (customer_id, month_total) ' + N'SELECT customer_id, month_total FROM #monthly'; EXEC sp_executesql @sql; END<\/code><\/pre>\n\n\n\n
El gr\u00e1fico de linaje correcto supera ambos obst\u00e1culos: pedidos.cantidad<\/code> \u2192 SUMA()<\/code> \u2192 #mensual.total_mes<\/code> \u2192 instant\u00e1nea_mensual.total_mes<\/code>, con pedidos.fecha_del_pedido<\/code> como un borde indirecto a trav\u00e9s del D\u00d3NDE<\/code> cl\u00e1usula y la @mes<\/code> par\u00e1metro rastreado como una entrada para ese filtro. Para llegar all\u00ed se requiere un analizador procedimental T-SQL real (no un divisor de sentencias), seguimiento de tabla temporal a trav\u00e9s de sentencias y resoluci\u00f3n de la cadena SQL entregada a sp_executesql<\/code>SQLFlow cuenta con analizadores procedimentales espec\u00edficos para SQL Server T-SQL y Oracle PL\/SQL, resuelve SQL din\u00e1mico dentro de los procedimientos y, adem\u00e1s, genera un gr\u00e1fico de llamadas que muestra qu\u00e9 procedimientos invocan a cu\u00e1les, lo que permite visualizar el linaje entre procedimientos. El SQL din\u00e1mico es el punto ciego m\u00e1s com\u00fan en las herramientas de linaje; si eval\u00faa alguna herramienta, pru\u00e9bela primero con este patr\u00f3n.<\/p>\n\n<\/div><\/div>\n\n\n\n
Ejemplo 5: cadena de modelos dbt<\/h2>\n\n\n\n
dbt te ofrece linaje a nivel de modelo listo para usar a trav\u00e9s de \u00e1rbitro()<\/code>Pero la pregunta interesante es a nivel de columna: \u00bfqu\u00e9 campo de origen alimenta qu\u00e9 columna del almac\u00e9n de datos, a trav\u00e9s de qu\u00e9 cambios de nombre en la zona de preparaci\u00f3n?<\/p>\n\n\n\n
-- models\/staging\/stg_orders.sql SELECT id AS order_id, customer_id, amount, status FROM {{ source('raw', 'orders') }} -- models\/marts\/fct_customer_revenue.sql SELECT customer_id, SUM(amount) AS lifetime_revenue FROM {{ ref('stg_orders') }} WHERE status = 'completed' GROUP BY customer_id<\/code><\/pre>\n\n\n\n
Importa el manifiesto dbt del proyecto en SQLFlow y el gr\u00e1fico resolver\u00e1 las referencias de plantilla en una cadena de columnas concreta: cantidad.de.pedidos.crudos<\/code> \u2192 stg_orders.amount<\/code> \u2192 SUMA()<\/code> \u2192 fct_ingresos_clientes.ingresos_de_vida<\/code>, con el cambio de nombre identificaci\u00f3n<\/code> \u2192 ID de pedido<\/code> conservado en el salto de etapa y estado<\/code> Se transmite como una arista indirecta desde el filtro del almac\u00e9n. Dado que el manifiesto vincula los modelos con los objetos del almac\u00e9n que crean, el mismo gr\u00e1fico concilia el linaje administrado por dbt con todo lo dem\u00e1s que toca esas tablas fuera de dbt.<\/p>\n\n\n\n
Ejemplo 6: ETL entre bases de datos<\/h2>\n\n\n\n
El sector inmobiliario abarca diversos motores. Un flujo t\u00edpico consiste en extraer una base de datos operativa de SQL Server a un almacenamiento en la nube, cargarla en el entorno de pruebas de Snowflake y, posteriormente, transformarla en un esquema anal\u00edtico. El proceso de carga y transformaci\u00f3n se ve as\u00ed:<\/p>\n\n\n\n
-- Snowflake COPIAR EN staging.orders_raw DESDE @s3_extract\/orders\/; INSERTAR EN analytics.fct_orders (order_id, customer_id, amount_usd) SELECCIONAR r.order_id, r.customer_id, r.amount * fx.rate DESDE staging.orders_raw r UNIR staging.fx_rates fx EN fx.currency = r.currency;<\/code><\/pre>\n\n\n\n
Dentro del lado de Copo de Nieve, el gr\u00e1fico muestra cantidad_USD<\/code> como una columna calculada con dos padres directos, cantidad_bruta_de_pedidos<\/code> y fx_rates.rate<\/code>, unidos mediante la expresi\u00f3n aritm\u00e9tica, m\u00e1s divisa<\/code> como un borde indirecto de la condici\u00f3n de uni\u00f3n. Para cubrir toda la canalizaci\u00f3n, se alimentan ambos lados de SQLFlow en sus propios dialectos: la l\u00f3gica de extracci\u00f3n T-SQL analizada con el analizador de SQL Server y los scripts de Snowflake analizados con el analizador de Snowflake, de un total de 39 analizadores espec\u00edficos de dialecto. En implementaciones empresariales, los resultados se almacenan en un repositorio de linaje persistente que escanea por lotes conjuntos de m\u00e1s de 100 bases de datos y m\u00e1s de un mill\u00f3n de columnas, de modo que la imagen de extremo a extremo de SQL Server a Snowflake reside en un solo gr\u00e1fico y se puede exportar a DataHub, Microsoft Purview u OpenMetadata.<\/p>\n\n\n\n
Lo que tienen en com\u00fan los seis ejemplos<\/h2>\n\n\n\n
Cada gr\u00e1fico anterior se deriv\u00f3 exclusivamente del texto SQL y los metadatos del esquema. Ese es el m\u00e9todo principal detr\u00e1s de Linaje de datos basado en SQL<\/a>Dado que la l\u00f3gica de transformaci\u00f3n ya reside en SQL, el an\u00e1lisis est\u00e1tico de ese SQL reconstruye el linaje sin agentes, sin acceso al registro de consultas y sin leer jam\u00e1s una sola fila de sus datos. Las diferencias entre los ejemplos radican \u00fanicamente en la dificultad del an\u00e1lisis, desde un \u00fanico INSERTAR-SELECCIONAR<\/code> para SQL din\u00e1mico dentro de un procedimiento.<\/p>\n\n\n\n
\n
Ejemplo<\/th>Lo que hace<\/th>La parte dif\u00edcil<\/th><\/tr><\/thead>
1. INSERTAR-SELECCIONAR<\/td>bordes directos versus indirectos<\/td>Modelado D\u00d3NDE<\/code>\/UNIRSE<\/code> columnas como linaje<\/td><\/tr>\n
2. CTE m\u00faltiple<\/td>Relaciones intermedias<\/td>Entradas de la funci\u00f3n de ventana; ruta de filtrado por rango<\/td><\/tr>\n
3. Ver cadena<\/td>Definiciones anidadas<\/td>Expansi\u00f3n estelar; detecci\u00f3n de columnas muertas<\/td><\/tr>\n
4. Procedimiento almacenado<\/td>C\u00f3digo de procedimiento<\/td>Tablas temporales y resoluci\u00f3n SQL din\u00e1mica<\/td><\/tr>\n
5. Cadena dbt<\/td>SQL con plantillas<\/td>Resolviendo \u00e1rbitro()<\/code>\/fuente()<\/code> a objetos reales<\/td><\/tr>\n
6. ETL entre bases de datos<\/td>M\u00faltiples dialectos<\/td>Integraci\u00f3n de gr\u00e1ficos por motor en un \u00fanico repositorio<\/td><\/tr>\n<\/tbody><\/table><\/figure>\n\n\n\n
\n\n
Consulte el linaje de su propio SQL.<\/h2>\n\n\n
Pegue cualquier consulta, procedimiento o script y obtenga el gr\u00e1fico a nivel de columna en segundos.<\/p>\n\n\n
\n
Prueba SQLFlow gratis<\/a><\/div>\n\n\n
Consulte la herramienta de linaje.<\/a><\/div>\n<\/div>\n\n<\/div><\/div>\n\n\n\n
Preguntas frecuentes<\/h2>\n\n\n\n
\u00bfQu\u00e9 es un diagrama de linaje de datos?<\/h3>\n\n\n
Un diagrama de linaje de datos es un grafo dirigido en el que los nodos representan tablas, vistas o columnas, y las aristas muestran c\u00f3mo fluyen los datos entre ellas mediante transformaciones SQL. Los diagramas a nivel de columna, como los descritos en esta p\u00e1gina, dibujan una arista por cada relaci\u00f3n entre una columna de origen y una de destino, anotada con la funci\u00f3n o cl\u00e1usula que la cre\u00f3.<\/p>\n\n\n\n
\u00bfPuedo reproducir estos ejemplos yo mismo?<\/h3>\n\n\n
S\u00ed. Pegue cualquiera de los fragmentos SQL anteriores en el Visualizador SQLFlow gratuito<\/a>Seleccione el dialecto correspondiente y el diagrama interactivo aparecer\u00e1 en segundos. La edici\u00f3n en la nube tiene una versi\u00f3n gratuita.<\/p>\n\n\n\n
\u00bfCu\u00e1l es la diferencia entre linaje directo e indirecto?<\/h3>\n\n\n
El linaje directo significa que los datos fluyen desde una columna de origen a una columna de destino, por ejemplo SUMA(pedidos.cantidad)<\/code> alimentaci\u00f3n cantidad_total<\/code>. El linaje indirecto significa que una columna influye en el resultado sin aparecer en \u00e9l, como por ejemplo una D\u00d3NDE<\/code> filtro o UNIRSE<\/code> clave. SQLFlow realiza un seguimiento de ambos como tipos de borde separados y conmutables; la mayor\u00eda de las herramientas solo capturan el flujo directo.<\/p>\n\n\n\n
\u00bfEs posible extraer el linaje de procedimientos almacenados y SQL din\u00e1mico?<\/h3>\n\n\n
S\u00ed, pero necesita un analizador procedimental, no solo un analizador de consultas. SQLFlow cuenta con analizadores espec\u00edficos para Oracle PL\/SQL y SQL Server T-SQL, rastrea el linaje a trav\u00e9s de par\u00e1metros y tablas temporales, resuelve cadenas SQL construidas dentro de procedimientos y dibuja el gr\u00e1fico de llamadas entre procedimientos.<\/p>\n\n\n\n
\u00bfLas herramientas de c\u00f3digo abierto manejan estos ejemplos?<\/h3>\n\n\n
Parcialmente. Bibliotecas como sqllineage<\/code> y sqlglot<\/code> Son realmente eficaces analizando consultas individuales y manejan bien los ejemplos 1 y 2. Los ejemplos que vale la pena probar antes de confirmar son del 4 al 6: c\u00f3digo procedimental con SQL din\u00e1mico, linaje indirecto como un tipo de arista independiente y la integraci\u00f3n de un conjunto de dialectos en un gr\u00e1fico interactivo. Ejecute su procedimiento almacenado m\u00e1s complejo con cualquier herramienta que eval\u00fae y compare los resultados.<\/p>\n\n\n\n
\u00bfCon qu\u00e9 dialectos SQL funcionan estos ejemplos?<\/h3>\n\n\n
SQLFlow incluye 39 analizadores sint\u00e1cticos espec\u00edficos para distintos dialectos, como Snowflake, BigQuery, Redshift, Databricks, Oracle, SQL Server, PostgreSQL, MySQL, Teradata, Hive, Spark SQL y Trino. Los ejemplos anteriores utilizan sintaxis SQL gen\u00e9rica, T-SQL, SQL con plantillas dbt y Snowflake, y cada una se analiza con su propia gram\u00e1tica en lugar de una gen\u00e9rica ANSI.<\/p>\n\n\n\n
\n\n
Convierta su propio SQL en un diagrama de linaje.<\/h2>\n\n\n
Pegue una consulta, un procedimiento o un script completo en el visualizador gratuito y obtenga el gr\u00e1fico a nivel de columna en segundos. Para entornos con m\u00faltiples bases de datos, cons\u00faltenos sobre el repositorio empresarial.<\/p>\n\n\n
\n
Prueba SQLFlow gratis<\/a><\/div>\n\n\n
Solicite una demostraci\u00f3n para empresas.<\/a><\/div>\n<\/div>\n\n<\/div><\/div>\n\n\n\n