{"id":6517,"date":"2026-09-15T08:36:00","date_gmt":"2026-09-15T06:36:00","guid":{"rendered":"https:\/\/blog-david.moreno-morales.com\/?p=6517"},"modified":"2026-09-13T21:38:12","modified_gmt":"2026-09-13T19:38:12","slug":"sql-con-inteligencia-artificial","status":"publish","type":"post","link":"https:\/\/blog-david.moreno-morales.com\/index.php\/2026\/09\/15\/sql-con-inteligencia-artificial\/","title":{"rendered":"SQL con inteligencia artificial: c\u00f3mo preparar tus datos para consultas fiables en lenguaje natural"},"content":{"rendered":"\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Preguntar a una base de datos en lenguaje natural ya no es una demostraci\u00f3n futurista. Cada vez m\u00e1s herramientas permiten escribir una pregunta como \u201c\u00bfqu\u00e9 productos aumentaron sus ventas durante el \u00faltimo trimestre?\u201d y obtener como respuesta una consulta SQL, una tabla o incluso una visualizaci\u00f3n.<\/p>

El problema aparece cuando pasamos de la demo a producci\u00f3n.<\/p>

Una consulta puede ser SQL perfectamente v\u00e1lido y, aun as\u00ed, responder mal a la pregunta de negocio. Puede utilizar una fecha incorrecta, unir tablas por una relaci\u00f3n equivocada, duplicar importes, interpretar \u201ccliente activo\u201d de forma distinta a la organizaci\u00f3n o calcular ingresos con una f\u00f3rmula diferente a la que utiliza Finanzas.<\/p>

Por eso, construir un buen sistema de lenguaje natural a SQL \u2014NL\u2192SQL o text-to-SQL\u2014 no consiste \u00fanicamente en elegir un modelo potente. Tambi\u00e9n exige preparar los datos para que la IA pueda entenderlos.<\/p>

Las plataformas actuales est\u00e1n evolucionando precisamente en esa direcci\u00f3n. Snowflake utiliza vistas sem\u00e1nticas para representar entidades, dimensiones, m\u00e9tricas y relaciones; Databricks permite enriquecer sus agentes Genie con instrucciones, consultas de ejemplo y activos confiables; BigQuery utiliza metadatos de su cat\u00e1logo para localizar los conjuntos adecuados; y Microsoft recomienda esquemas con nombres suficientemente descriptivos para que Copilot pueda interpretar mejor la base de datos.<\/p>

La conclusi\u00f3n es importante: la calidad del SQL generado por IA empieza mucho antes del prompt.<\/p>

El problema de darle a la IA solamente el esquema<\/h2>

Imaginemos una base de datos con estas tablas:<\/p>

tb_cli\ntb_mov\ntb_prd<\/code><\/pre>
Y columnas como:<\/p>
id_cli\nf_mov\nimp_n\nst\ntp<\/code><\/pre>
Para una persona que conoce el sistema desde hace a\u00f1os quiz\u00e1 sea suficiente. Para un modelo de IA, la informaci\u00f3n disponible es extremadamente pobre.<\/p>
\u00bfQu\u00e9 significa st<\/code>?<\/p>
\u00bfEstado de la operaci\u00f3n? \u00bfEstado del cliente? \u00bfProvincia?<\/p>
\u00bfimp_n<\/code> representa importe neto, importe nominal o importe sin impuestos?<\/p>
\u00bfUna fila de tb_mov<\/code> corresponde a una venta, a una l\u00ednea de factura o a un movimiento de inventario?<\/p>
El modelo puede intentar deducirlo. Y precisamente ah\u00ed empieza el riesgo.<\/p>
Un sistema NL\u2192SQL fiable debe reducir al m\u00ednimo las situaciones en las que el modelo tenga que adivinar.<\/p>
1. Utiliza nombres que expliquen el modelo de datos<\/h2>
Una de las mejoras m\u00e1s sencillas es tambi\u00e9n una de las m\u00e1s efectivas: utilizar nombres claros.<\/p>
En lugar de:<\/p>
tb_cli<\/code><\/pre>
preferimos:<\/p>
customers<\/code><\/pre>
En lugar de:<\/p>
f_alta<\/code><\/pre>
podemos utilizar:<\/p>
customer_registration_date<\/code><\/pre>
Y en lugar de:<\/p>
imp_n<\/code><\/pre>
algo como:<\/p>
net_sales_amount<\/code><\/pre>
Microsoft se\u00f1ala precisamente que la conversi\u00f3n de lenguaje natural a SQL depende de nombres expresivos en tablas y columnas. Si los nombres no describen suficientemente el dato, el asistente dispone de menos contexto para construir una consulta significativa.<\/p>
Esto no significa escribir identificadores interminables. Significa priorizar claridad frente a abreviaturas que solo entiende el equipo que cre\u00f3 originalmente la aplicaci\u00f3n.<\/p>
2. Declara las relaciones en lugar de obligar al modelo a deducirlas<\/h2>
Las claves primarias y for\u00e1neas no son \u00fanicamente restricciones de integridad.<\/p>
Tambi\u00e9n son documentaci\u00f3n estructurada.<\/p>
Por ejemplo:<\/p>
customers\n---------\ncustomer_id PK\n\norders\n------\norder_id PK\ncustomer_id FK -> customers.customer_id<\/code><\/pre>
Para un asistente SQL, esta relaci\u00f3n aporta una se\u00f1al mucho m\u00e1s fiable que intentar inferir el JOIN<\/code> \u00fanicamente comparando nombres de columnas.<\/p>
El problema es especialmente importante en modelos grandes.<\/p>
Supongamos que existen:<\/p>
customers\norders\norder_items\nproducts\npayments\nshipments\nsales_representatives\nterritories<\/code><\/pre>
Cuando un usuario pregunta: \u00bfCu\u00e1les fueron las ventas por territorio?<\/p>
pueden existir diferentes caminos para relacionar territorio y venta. Si el modelo tiene que elegirlos por intuici\u00f3n, aumenta la probabilidad de obtener una consulta sint\u00e1cticamente correcta pero sem\u00e1nticamente equivocada.<\/p>
Las capas sem\u00e1nticas modernas intentan resolver precisamente este problema definiendo de forma expl\u00edcita las relaciones y rutas de uni\u00f3n. Snowflake, por ejemplo, incluye las relaciones entre entidades dentro de sus Semantic Views.<\/p>
3. No expongas todo el modelo f\u00edsico<\/h2>
Otro error habitual consiste en conectar el asistente directamente a cientos o miles de tablas operacionales. M\u00e1s contexto no significa necesariamente mejor contexto.<\/p>
Un ERP puede tener decenas de tablas relacionadas con clientes:<\/p>
customers\ncustomer_addresses\ncustomer_contacts\ncustomer_history\ncustomer_status_history\ncustomer_preferences\ncustomer_segments\ncustomer_import\ncustomer_archive<\/code><\/pre>
Si la pregunta es \u201c\u00bfcu\u00e1ntos clientes activos tenemos?\u201d, entregar todas esas tablas al modelo puede a\u00f1adir ambig\u00fcedad en lugar de eliminarla.<\/p>
Una estrategia m\u00e1s robusta consiste en construir una superficie de datos pensada para an\u00e1lisis.<\/p>
Por ejemplo:<\/p>
analytics.customers\nanalytics.sales\nanalytics.products\nanalytics.calendar<\/code><\/pre>
Estas vistas pueden ocultar complejidad t\u00e9cnica, normalizar nombres y presentar \u00fanicamente las columnas necesarias. Para sistemas de IA, una buena vista no es simplemente una comodidad para el analista, es una interfaz.<\/p>
4. Construye una capa sem\u00e1ntica<\/h2>
Aqu\u00ed encontramos uno de los cambios m\u00e1s importantes que est\u00e1 produciendo la IA en los sistemas de datos. El esquema f\u00edsico explica c\u00f3mo se almacenan los datos.<\/p>
La capa sem\u00e1ntica explica qu\u00e9 significan.<\/p>
Una organizaci\u00f3n puede definir, por ejemplo:<\/p>
M\u00e9trica: ingresos netos\nDefinici\u00f3n: ventas brutas - descuentos - devoluciones<\/code><\/pre>
O:<\/p>
Cliente activo:\ncliente que ha realizado al menos una compra\ndurante los \u00faltimos 12 meses.<\/code><\/pre>
Sin esta definici\u00f3n, preguntas aparentemente simples pueden producir respuestas diferentes.<\/p>
\u00bfQu\u00e9 significa \u201cventas\u201d? \u00bfImporte facturado? \u00bfCobrado? \u00bfPedidos confirmados? \u00bfImporte sin IVA? \u00bfImporte despu\u00e9s de devoluciones?<\/p>
La IA no puede resolver correctamente estas ambig\u00fcedades si la organizaci\u00f3n nunca las ha formalizado.<\/p>
Snowflake describe sus Semantic Views precisamente como una capa que representa entidades, dimensiones, hechos, m\u00e9tricas y relaciones utilizando conceptos de negocio. Adem\u00e1s, recomienda este enfoque para nuevas implementaciones de an\u00e1lisis conversacional.<\/p>
La capa sem\u00e1ntica deja as\u00ed de ser \u00fanicamente una herramienta de BI. Se convierte en infraestructura para IA.<\/p>
5. A\u00f1ade descripciones y sin\u00f3nimos<\/h2>
Los usuarios no siempre utilizan el mismo vocabulario que la base de datos.<\/p>
La tabla puede llamarse: sales_representatives<\/code><\/p>
mientras que las personas preguntan por:<\/p>
comerciales\nvendedores\nrepresentantes\nequipo de ventas<\/code><\/pre>
Una capa orientada a IA deber\u00eda poder relacionar estos conceptos. Lo mismo ocurre con m\u00e9tricas. El usuario puede decir: facturaci\u00f3n<\/p>
mientras el modelo de datos habla de: net_revenue<\/code><\/p>
A\u00f1adir descripciones, etiquetas y sin\u00f3nimos reduce esa distancia entre lenguaje humano y modelo f\u00edsico.<\/p>
Este enriquecimiento de metadatos es uno de los motivos por los que las plataformas modernas est\u00e1n trasladando cada vez m\u00e1s informaci\u00f3n sem\u00e1ntica al cat\u00e1logo de datos.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\"Base\t\t\t\t\t\t\t\t\t\t\t
Base de datos ambigua vs. preparada para IA<\/figcaption>\n\t\t\t\t\t\t\t\t\t\t<\/figure>\n\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\"Arquitectura\t\t\t\t\t\t\t\t\t\t\t
Arquitectura segura de NL\u2192SQL<\/figcaption>\n\t\t\t\t\t\t\t\t\t\t<\/figure>\n\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t
6. Proporciona consultas SQL verificadas<\/h2>
Uno de los mecanismos m\u00e1s potentes para mejorar un sistema NL\u2192SQL consiste en proporcionar pares de pregunta y SQL que sabemos que son correctos.<\/p>
Por ejemplo:<\/p>
Pregunta<\/strong><\/p>
\u00bfCu\u00e1les fueron los cinco productos con mayores\ningresos netos durante el \u00faltimo trimestre?<\/code><\/pre>
Consulta verificada<\/strong><\/p>
SELECT\n    p.product_name,\n    SUM(s.net_sales_amount) AS net_revenue\nFROM analytics.sales AS s\nJOIN analytics.products AS p\n    ON s.product_id = p.product_id\nWHERE s.sale_date >= DATE_TRUNC('quarter', CURRENT_DATE) - INTERVAL '3 months'\n  AND s.sale_date < DATE_TRUNC('quarter', CURRENT_DATE)\nGROUP BY p.product_name\nORDER BY net_revenue DESC\nLIMIT 5;<\/code><\/pre>
Estos ejemplos cumplen dos funciones.<\/p>
Primero, muestran al sistema c\u00f3mo se traducen conceptos de negocio a estructuras SQL. Segundo, proporcionan casos conocidos contra los que podemos evaluar nuevas versiones.<\/p>
Snowflake incorpora consultas verificadas como mecanismo para mejorar la confianza y tambi\u00e9n las utiliza como base para evaluar la precisi\u00f3n de Cortex Analyst.<\/p>
Databricks sigue una filosof\u00eda similar mediante consultas SQL de ejemplo y activos confiables configurados dentro de Genie.<\/p>
7. Trata la generaci\u00f3n de SQL como un sistema que necesita pruebas<\/h2>
Cambiar el modelo, modificar una descripci\u00f3n o a\u00f1adir una tabla puede alterar las consultas generadas. Por eso necesitamos pruebas de regresi\u00f3n. Podemos construir un conjunto de preguntas como:<\/p>
\u00bfCu\u00e1ntos clientes activos tenemos?\n\n\u00bfCu\u00e1l fue el ingreso neto del mes pasado?\n\n\u00bfQu\u00e9 categor\u00eda tiene mayor margen?\n\n\u00bfCu\u00e1les son los diez clientes con m\u00e1s compras?\n\n\u00bfC\u00f3mo evolucionaron las ventas interanuales?<\/code><\/pre>
Para cada pregunta almacenamos una consulta o un resultado esperado. Despu\u00e9s evaluamos cada nueva versi\u00f3n del sistema.<\/p>
No es necesario exigir que el SQL generado sea id\u00e9ntico car\u00e1cter por car\u00e1cter. Dos consultas diferentes pueden producir correctamente el mismo resultado.<\/p>
Lo importante es validar aspectos como:<\/p>
  • tablas utilizadas;<\/li>
  • relaciones;<\/li>
  • filtros;<\/li>
  • m\u00e9tricas;<\/li>
  • agregaciones;<\/li>
  • periodo temporal;<\/li>
  • resultado final.<\/li><\/ul>
    La evaluaci\u00f3n continua convierte el NL\u2192SQL en ingenier\u00eda y no simplemente en prompting.<\/p>
    8. Introduce guardrails antes de ejecutar la consulta<\/h2>
    Generar SQL y ejecutar SQL son dos problemas diferentes, aunque el sistema produzca una consulta v\u00e1lida, no deber\u00edamos asumir autom\u00e1ticamente que es segura.<\/p>
    Una arquitectura sencilla puede funcionar as\u00ed:<\/p>
    Pregunta del usuario\n        \u2193\nRecuperaci\u00f3n de contexto\n        \u2193\nGeneraci\u00f3n SQL\n        \u2193\nValidaci\u00f3n\n        \u2193\nEjecuci\u00f3n controlada\n        \u2193\nResultado<\/code><\/pre>
    Entre generaci\u00f3n y ejecuci\u00f3n podemos introducir controles. Por ejemplo:<\/p>
    Solo lectura<\/h3>
    El usuario destinado a an\u00e1lisis puede disponer \u00fanicamente de permisos SELECT<\/code>.<\/p>
    De esta forma, incluso si el modelo genera accidentalmente:<\/p>
    DELETE FROM customers;<\/code><\/pre>
    la base de datos rechazar\u00e1 la operaci\u00f3n.<\/p>
    Lista de objetos permitidos<\/h3>
    El asistente puede consultar \u00fanicamente determinadas vistas anal\u00edticas.<\/p>
    L\u00edmites<\/h3>
    Podemos imponer l\u00edmites de filas o tiempo de ejecuci\u00f3n.<\/p>
    An\u00e1lisis previo<\/h3>
    Antes de ejecutar podemos comprobar:<\/p>
    • presencia de DELETE<\/code>, UPDATE<\/code>, DROP<\/code> o ALTER<\/code>;<\/li>
    • joins sin condiciones;<\/li>
    • consultas contra tablas prohibidas;<\/li>
    • estimaciones de coste excesivas.<\/li><\/ul>
      Microsoft aplica una separaci\u00f3n similar en sus experiencias Copilot: las respuestas generadas deben revisarse y las operaciones que pueden modificar datos requieren intervenci\u00f3n o aprobaci\u00f3n del usuario. La documentaci\u00f3n tambi\u00e9n advierte expresamente de que las consultas generadas pueden ser inexactas.<\/p>
      9. Respeta los permisos del usuario<\/h2>
      Un asistente no deber\u00eda convertirse en una v\u00eda alternativa para saltarse el modelo de seguridad.<\/p>
      Si una persona no puede consultar salarios mediante SQL convencional, tampoco deber\u00eda poder obtenerlos preguntando: \u00bfCu\u00e1l es el salario medio de cada empleado?<\/p>
      La ejecuci\u00f3n debe realizarse con permisos equivalentes a los del usuario o mediante una pol\u00edtica perfectamente controlada.<\/p>
      Databricks, por ejemplo, eval\u00faa el acceso a los datos de Genie utilizando los permisos de Unity Catalog del usuario final.<\/p>
      El principio general es sencillo: la IA no sustituye el gobierno del dato; debe trabajar dentro de \u00e9l.<\/p>
      10. Registra pregunta, SQL y resultado<\/h2>
      Un sistema en producci\u00f3n necesita observabilidad. Como m\u00ednimo conviene registrar:<\/p>
      pregunta\ncontexto utilizado\nSQL generado\ntiempo de ejecuci\u00f3n\nerror\nusuario\nfeedback<\/code><\/pre>
      Esto permite descubrir patrones. Quiz\u00e1 muchas consultas fallen cuando aparece la palabra \u201cfacturaci\u00f3n\u201d. Quiz\u00e1 una relaci\u00f3n concreta produzca duplicados.<\/p>
      Quiz\u00e1 los usuarios utilicen un t\u00e9rmino que todav\u00eda no existe como sin\u00f3nimo en la capa sem\u00e1ntica.<\/p>
      Los errores dejan entonces de ser casos aislados y pasan a convertirse en informaci\u00f3n para mejorar el sistema.<\/p>
      Una arquitectura pr\u00e1ctica<\/h2>
      Una arquitectura razonable para un asistente SQL podr\u00eda dividirse en cinco capas.<\/p>
      1. Datos f\u00edsicos<\/h3>
      Las tablas originales:<\/p>
      ERP\nCRM\ne-commerce\nfacturaci\u00f3n\nsoporte<\/code><\/pre>
      2. Modelo anal\u00edtico<\/h3>
      Vistas o tablas curadas:<\/p>
      customers\nsales\nproducts\ncalendar<\/code><\/pre>
      3. Capa sem\u00e1ntica<\/h3>
      Aqu\u00ed viven:<\/p>
      m\u00e9tricas\ndimensiones\nrelaciones\ndefiniciones\nsin\u00f3nimos\nreglas de negocio<\/code><\/pre>
      4. Sistema NL\u2192SQL<\/h3>
      El modelo recibe \u00fanicamente el contexto relevante y genera la consulta.<\/p>
      5. Validaci\u00f3n y ejecuci\u00f3n<\/h3>
      Finalmente se aplican permisos, l\u00edmites, comprobaciones y observabilidad.<\/p>
      La arquitectura ser\u00eda:<\/p>
      Usuario\n   \u2193\nLenguaje natural\n   \u2193\nContexto + capa sem\u00e1ntica\n   \u2193\nLLM \/ agente SQL\n   \u2193\nSQL generado\n   \u2193\nValidador\n   \u2193\nMotor SQL\n   \u2193\nResultado<\/code><\/pre>
      La mayor parte de la fiabilidad no procede exclusivamente de la caja \u201cLLM\u201d. Procede de todo lo que la rodea.<\/p>
      Checklist para preparar SQL para IA<\/h2>
      Antes de conectar un asistente de lenguaje natural a una base de datos, merece la pena revisar:<\/p>
      • \u00bfLas tablas tienen nombres comprensibles?<\/li>
      • \u00bfLas columnas expresan claramente qu\u00e9 representan?<\/li>
      • \u00bfLas claves primarias y for\u00e1neas est\u00e1n declaradas?<\/li>
      • \u00bfLas relaciones importantes est\u00e1n documentadas?<\/li>
      • \u00bfLas m\u00e9tricas de negocio tienen una \u00fanica definici\u00f3n?<\/li>
      • \u00bfExisten vistas anal\u00edticas que oculten complejidad innecesaria?<\/li>
      • \u00bfSe han definido sin\u00f3nimos del vocabulario utilizado por los usuarios?<\/li>
      • \u00bfTenemos preguntas y consultas verificadas?<\/li>
      • \u00bfExiste un conjunto de pruebas de regresi\u00f3n?<\/li>
      • \u00bfEl usuario de ejecuci\u00f3n tiene permisos m\u00ednimos?<\/li>
      • \u00bfLas consultas generadas pasan por un validador?<\/li>
      • \u00bfRegistramos errores y feedback?<\/li><\/ul>
        Cuantas m\u00e1s respuestas sean afirmativas, menos depender\u00e1 el sistema de que el modelo \u201cadivine\u201d.<\/p>
        Conclusi\u00f3n<\/h2>
        La llegada de la IA est\u00e1 oblig\u00e1ndonos a mirar las bases de datos desde una perspectiva nueva. Durante a\u00f1os optimizamos esquemas para aplicaciones, desarrolladores y herramientas de BI.<\/p>
        Ahora tenemos un nuevo consumidor: los modelos de lenguaje. Y estos modelos funcionan mejor cuando el significado est\u00e1 expl\u00edcito.<\/p>
        Un esquema limpio ayuda, las relaciones ayudan, las vistas ayudan.<\/p>
        Pero el verdadero salto aparece cuando a\u00f1adimos una capa sem\u00e1ntica con m\u00e9tricas, conceptos, sin\u00f3nimos y ejemplos verificados, y posteriormente rodeamos la generaci\u00f3n SQL de permisos, validaci\u00f3n y evaluaci\u00f3n.<\/p>
        Por eso, antes de buscar un modelo m\u00e1s grande para mejorar tu sistema NL\u2192SQL, merece la pena hacer una pregunta diferente:<\/p>
        \u00bfEntender\u00eda alguien nuevo en tu equipo lo que significa tu modelo de datos sin tener que preguntarte nada?<\/strong><\/p>
        Si la respuesta es no, probablemente la IA tampoco.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
        \n\t\t\t\t\t\t
        \n\t\t\t\t\t
        \n\t\t\t
        \n\t\t\t\t\t\t
        \n\t\t\t\t\t
        REFERENCIAS\n<\/h4>\t\t\t\t<\/div>\n\t\t\t\t
        \n\t\t\t\t\t\t\t\t\t
        • Snowflake \u2014 Cortex Analyst y Semantic Views.<\/li>
        • Snowflake \u2014 buenas pr\u00e1cticas y evaluaci\u00f3n mediante consultas verificadas.<\/li>
        • Snowflake \u2014 instrucciones personalizadas para generaci\u00f3n SQL, incorporadas a Semantic Views durante 2026.<\/li>
        • Databricks \u2014 Genie Agents, Unity Catalog, instrucciones, consultas de ejemplo y trusted assets.<\/li>
        • Google Cloud \u2014 BigQuery Data Canvas y uso de metadatos de cat\u00e1logo para consultas en lenguaje natural.<\/li>
        • Microsoft \u2014 Copilot para SQL Database en Fabric, recomendaciones sobre nombres descriptivos, permisos y validaci\u00f3n humana.<\/li><\/ul>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t<\/div>\n\t\t","protected":false},"excerpt":{"rendered":"
          C\u00f3mo dise\u00f1ar esquemas, vistas, nombres, relaciones y una capa sem\u00e1ntica que permita a asistentes de IA generar consultas SQL m\u00e1s correctas y verificables.<\/p>\n","protected":false},"author":1,"featured_media":6518,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[39],"tags":[67,57,49,52,53,48,68],"class_list":["post-6517","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-bbdd","tag-base-de-datos","tag-bi","tag-ia","tag-inteligenciaartificial","tag-modelo-de-lenguaje","tag-software","tag-sql"],"_links":{"self":[{"href":"https:\/\/blog-david.moreno-morales.com\/index.php\/wp-json\/wp\/v2\/posts\/6517","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog-david.moreno-morales.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog-david.moreno-morales.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog-david.moreno-morales.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog-david.moreno-morales.com\/index.php\/wp-json\/wp\/v2\/comments?post=6517"}],"version-history":[{"count":3,"href":"https:\/\/blog-david.moreno-morales.com\/index.php\/wp-json\/wp\/v2\/posts\/6517\/revisions"}],"predecessor-version":[{"id":6523,"href":"https:\/\/blog-david.moreno-morales.com\/index.php\/wp-json\/wp\/v2\/posts\/6517\/revisions\/6523"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog-david.moreno-morales.com\/index.php\/wp-json\/wp\/v2\/media\/6518"}],"wp:attachment":[{"href":"https:\/\/blog-david.moreno-morales.com\/index.php\/wp-json\/wp\/v2\/media?parent=6517"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog-david.moreno-morales.com\/index.php\/wp-json\/wp\/v2\/categories?post=6517"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog-david.moreno-morales.com\/index.php\/wp-json\/wp\/v2\/tags?post=6517"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}