Geração de esquema SQL com grandes modelos de linguagem

Tendências de API: engenharia de plataforma, desagregação e papel da IA

7 de maio de 2024

Dicas para construir uma disciplina de engenharia de plataforma duradoura

7 de maio de 2024

Publicado por Douglas S. em 7 de maio de 2024

Categorias

Data Science

Tags

Geração de esquema SQL com grandes modelos de linguagem

Analisei a geração de persistência regex e JSON com LLMs, mas é a Linguagem de Consulta Estruturada (SQL) que muitos acreditam ser bem tratada pela IA. Para ajudar a comemorar o 50º aniversário do SQL, vamos falar sobre tabelas, apresentando a terminologia técnica conforme necessário. No entanto, não quero simplesmente testar consultas em tabelas existentes. O mundo de bancos de dados relacionais começa com o esquema.

Um esquema descreve um grupo de tabelas que interagem para permitir que consultas SQL respondam a perguntas sobre modelos de sistemas do mundo real. Usamos vários restrições para controlar como as tabelas se relacionam entre si. Neste exemplo, desenvolverei um esquema sobre livros, autores e editoras. Depois veremos se um LLM consegue reproduzir o trabalho.

Começamos com o relações entre nossas coisas. Um livro é escrito por um autor e publicado por uma editora. Na verdade, a publicação de um livro define a relação entre autor e editor.

Então, em termos concretos, queremos produzir um resultado como este:

Isso é agradável de ler (voltaremos a isso mais tarde), mas a tabela em si seria uma maneira ruim de manter mais informações.

Se o nome do editor for apenas uma string, pode ser necessário digitá-lo várias vezes, o que é ineficiente e propenso a erros. O mesmo para o autor. Aqueles com inclinação literária saberão que o autor (Iain Banks) é o mesmo para ambos os livros, mas ele usou um pseudônimo ligeiramente alterado ao escrever ficção científica.

E se o livro fosse lançado novamente mais tarde por uma editora diferente? Para ter certeza de distinguir entre os dois eventos de publicação, precisaríamos dos títulos dos livros e da data de lançamento – portanto, nosso chave primária ou identificação única deve incluir ambos. Queremos que o sistema rejeite qualquer tentativa de inscrição de dois livros com o mesmo título e data de publicação.

Em vez de usar uma tabela grande, vamos usar três tabelas e referências a elas quando necessário. Um para autores, um para editoras e outro para livros. Escrevemos os detalhes do autor na tabela Autores e depois os referenciamos na tabela Livros usando um chave estrangeira.

Então aqui estão as tabelas de esquema escritas em linguagem de definição de dados (DDL). Estou usando a variante MySQL – irritantemente, todos os fornecedores ainda mantêm dialetos ligeiramente diferentes.

Primeiro, a tabela de autores. Adicionamos um índice de coluna de ID automático como chave primária. Na verdade, não resolvemos o problema do pseudônimo (deixarei isso para os leitores):

CREATE TABLE Autores (ID int NOT NULL AUTO_INCREMENT, Nome varchar(255) não nulo, Data de aniversário não nula, CHAVE PRIMÁRIA (ID));

CRIAR MESA Autores (

EU IA interno NÃO NULO INCREMENTO AUTOMÁTICO,

O meu nome varchar(255) não nulo,

Aniversário data não nulo,

PRIMÁRIO CHAVE (EU IA)

);

A tabela de editores segue o mesmo padrão. O “NOT NULL” é outra restrição para evitar que dados sejam adicionados sem conteúdo.

CREATE TABLE Editores (ID int NOT NULL AUTO_INCREMENT, Nome varchar(255) não nulo, Endereço varchar(255) não nulo, PRIMARY KEY (ID) );

CRIAR MESA Editores (

EU IA interno NÃO NULO INCREMENTO AUTOMÁTICO,

O meu nome varchar(255) não nulo,

Endereço varchar(255) não nulo,

PRIMÁRIO CHAVE (EU IA)

);

A tabela Books fará referência às chaves estrangeiras, o que a deixa lógica, mas um pouco ilegível. Observe que respeitamos que o título do livro juntamente com a data de publicação constituem a chave primária.

CREATE TABLE Livros (Nome varchar(255) NOT NULL, AuthorID int, PublisherID int, PublishedDate data NOT NULL, PRIMARY KEY (Name, PublishedDate), FOREIGN KEY (AuthorID) REFERÊNCIAS Autores(ID), CHAVE ESTRANGEIRA (PublisherID) REFERÊNCIAS Editores( EU IA) );

CRIAR MESA Livros (

O meu nome varchar(255) NÃO NULO,

ID do autor interno, ID do editor interno,

Data de publicação data NÃO NULO,

PRIMÁRIO CHAVE (O meu nome, Data de publicação),

ESTRANGEIRO CHAVE (ID do autor) REFERÊNCIAS Autores(EU IA),

ESTRANGEIRO CHAVE (ID do editor) REFERÊNCIAS Editores(EU IA)

);

Para ver uma mesa organizada como a que está no topo, precisamos de um visualizar. Esta é apenas uma forma de unir tabelas para que possamos selecionar as informações que precisamos exibir, deixando o esquema intacto. Agora que temos o esquema escrito, podemos construir nossa visão:

CRIAR VISUALIZAR ViewableBooks AS SELECT Books.Name ‘Livro’, Authors.Name ‘Autor’, Publishers.Name ‘Publisher’, Books.PublishedDate ‘Date’ FROM Books, Publishers, Authors WHERE Books.AuthorID = Authors.ID AND Books.PublisherID = Editores.ID;

CRIAR VISUALIZAR Livros visíveis COMO

SELECIONAR Livros.O meu nome ‘livro’, Autores.O meu nome ‘Autor’, Editores.O meu nome ‘editor’, Livros.Data de publicação ‘Data’

DE Livros, Editores, Autores

ONDE Livros.ID do autor = Autores.EU IA

E Livros.ID do editor = Editores.EU IA;

Vamos ver se conseguimos produzir nosso esquema em um playground on-line para não precisarmos instalar um banco de dados. DB Fiddle deve fazer o trabalho.

Se você inserir o DDL e depois adicionar os dados reais:

INSERT INTO Autores (Nome, Aniversário) VALUES (‘Iain Banks’, ‘1954-02-16’); INSERT INTO Autores (nome, data de nascimento) VALUES (‘Iain M Banks’, ‘1954-02-16’); INSERT INTO Editores (Nome, Endereço) VALORES (‘Abacus’, ‘London’); INSERT INTO Editores (Nome, Endereço) VALORES (‘Orbit’, ‘New York’);

INSERIR EM Autores (O meu nome, Aniversário)

VALORES (‘Bancos Iain’, ’16/02/1954′);

INSERIR EM Autores (O meu nome, Aniversário)

VALORES (‘Iain M Bancos’, ’16/02/1954′);

INSERIR EM Editores (O meu nome, Endereço)

VALORES (‘Ábaco’, ‘Londres’);

INSERIR EM Editores (O meu nome, Endereço)

VALORES (‘Órbita’, ‘Nova Iorque’);

Os resultados da visualização são mostrados abaixo como ‘Consulta 3’ no DB Fiddle, e são os dados que queríamos ver o tempo todo:

Um LLM também pode criar esquemas?

OK, agora queremos perguntar a um LLM sobre a criação de esquemas. Para resumir como queremos orientar o LLM:

Quando solicitado em inglês por um esquema, queremos que ele gere o DDL para três tabelas, com índices e restrições.
Também podemos sugerir a necessidade de restrições (chaves primárias, chaves estrangeiras, etc.), se necessário.
Podemos pedir uma vista.
Podemos ajustá-lo à sintaxe do MySQL, se necessário.

Usarei o Llama 3, mas também dei uma olhada nos LLMs da OpenAI e obtive praticamente os mesmos resultados.

Nossa primeira consulta: “Crie um esquema de banco de dados relacional para descrever livros, editoras e autores”.

E os resultados:

Até agora tudo bem. Não criou o DDL, mas podemos perguntar isso separadamente. De certa forma, ele se saiu melhor ao descrever o esquema em inglês. Vejamos o resto da resposta:

Descreveu restrições de chave estrangeira e adicionou o ISBN, no qual não pensei. Além disso, “PublicationDate” é melhor em inglês do que meu “PublishedDate”. E fez mais uma mesa:

Isso resolve o problema de vários autores em um livro – não é um problema no qual eu estava pensando. O termo mesa de ponte indica a união das duas tabelas (livros e autores) via chaves estrangeiras.

Vamos solicitar o DDL: “Mostre-me a linguagem de definição de dados para este esquema.”

Eles retornaram corretamente, incluindo NOT NULLs para garantir que não haja entradas vazias. Ele também observou que o DDL era, de certa forma, “genérico” devido às diferenças entre os SQLs dos fornecedores no mundo real.

Por fim, vamos pedir uma vista:

Esta é uma versão muito mais complicada que a minha; no entanto, quando adaptado para a nomenclatura do meu esquema, funciona perfeitamente no DB Fiddle. A mesa apelido a nomenclatura vista aqui realmente não ajuda na compreensão.

Conclusão: LLMs podem realmente fazer esquemas

Eu diria que isso foi uma grande vitória para os LLMs, pois eles transformaram minha descrição em inglês em um esquema bem restrito e, em seguida, em DDL executável, ao mesmo tempo em que forneceram explicações (embora elas tenham entrado em detalhes mais técnicos de relacionamento). Eu nem usei um LLM ou serviço especializado, então funcionou bem.

Até certo ponto, este é um mapeamento de um domínio (o mundo editorial) para outro (a linguagem SQL específica do domínio), e isso funciona fortemente para os pontos fortes de um LLM. Cada domínio é bem definido e profundo em detalhes.

Então, feliz aniversário, SQL, e espero que os LLMs mantenham você relevante por mais algumas décadas!

David é desenvolvedor de software profissional baseado em Londres na Oracle Corp. e British Telecom, além de um consultor que auxilia as equipes a trabalhar de forma mais ágil. Ele escreveu um livro sobre UI design e tem escrito artigos técnicos desde então….