대규모 언어 모델을 사용하여 SQL 스키마 생성

오픈소스 중국 커뮤니티 팀이 공유라는 이름으로 오픈소스 중국 커뮤니티의 뒷이야기를 전하는 첫 생방송을 진행했습니다."

우리는 하나의 도메인(게시)을 다른 도메인(SQL의 도메인별 언어)으로 매핑하는 것이 LLM의 강점에 잘 맞는다는 것을 알았습니다.

David Eastman의 저자인 대규모 언어 모델을 사용한 SQL 스키마 생성 에서 번역되었습니다 .

LLM을 사용하여 생성된 정규식 및 JSON 지속성을 살펴봤지만 많은 사람들은 AI가 SQL(구조적 쿼리 언어)을 잘 처리한다고 믿고 있습니다. SQL의 50번째 생일을 축하하기 위해 필요한 경우 기술 용어를 소개하면서 테이블에 대해 논의해 보겠습니다. 그러나 기존 테이블에 대해 쿼리를 테스트하고 싶지는 않습니다 . 관계형 데이터베이스 의 세계는 스키마 로 시작됩니다 .

스키마는 SQL 쿼리가 실제 시스템 모델에 대한 질문에 답할 수 있도록 상호 작용하는 테이블 집합을 설명합니다. 다양한 제약 조건을 사용하여 테이블이 서로 관련되는 방식을 제어합니다. 이 예에서는 책, 작가, 출판사에 대한 스키마를 개발하겠습니다. 그런 다음 LLM이 이 작업을 복제할 수 있는지 살펴보겠습니다.

우리는 사물 간의 관계 부터 시작합니다 . 책은 작가가 쓰고 출판사가 출판합니다. 실제로 책의 출판은 저자와 출판사 간의 관계를 정의합니다.

따라서 구체적으로 다음과 같은 결과를 생성하고자 합니다.

책	작가	발행자	출시일
말벌 공장	이언 뱅크스	주판	1984년 2월 16일
플레바스(Plebas)를 고려해보세요	이언 M. 뱅크스	궤도	1988년 4월 14일

읽기에는 좋지만(나중에 다시 설명하겠습니다) 테이블 자체는 더 많은 정보를 유지 관리하는 좋은 방법이 아닙니다.

출판사 이름이 단순한 문자열인 경우 여러 번 입력해야 할 수도 있습니다. 이는 비효율적이고 오류가 발생하기 쉽습니다. 작가도 마찬가지다. 문학에 관심이 있는 분들은 두 책의 저자(Iain Banks)가 동일인이라는 사실을 아실 것입니다. 그러나 그는 SF 소설을 쓸 때 약간 다른 가명을 사용했습니다.

나중에 다른 출판사에서 책을 다시 출판하면 어떻게 되나요? 이 두 가지 출판 이벤트를 구별하려면 책 제목과 출시 날짜를 모두 제공해야 합니다. 따라서 기본 키 또는 고유 식별자에는 두 가지가 모두 포함되어야 합니다. 우리는 제목과 발행일이 동일한 두 권의 도서가 시스템에서 거부되기를 원합니다.

하나의 큰 테이블을 사용하는 대신 세 개의 테이블을 사용하여 필요할 때 참조합니다. 하나는 저자용, 하나는 출판사용, 하나는 책용입니다. Authors 테이블에 저자의 세부 정보를 기록한 다음 외래 키를 사용하여 Books 테이블에서 이를 참조합니다 .

따라서 다음은 DDL (Data Definition Language)을 사용하여 작성된 Schema 테이블 입니다. 저는 MySQL 변형을 사용하고 있습니다. 짜증나게도 모든 공급업체는 여전히 약간 다른 방언을 유지하고 있습니다.

먼저 작성자 테이블이 있습니다. 자동 ID 열 인덱스를 기본 키로 추가합니다. 우리는 실제로 가명 문제를 해결하지 못했습니다(이 문제는 독자에게 맡깁니다).

CREATE TABLE Authors ( 
  ID int NOT NULL AUTO_INCREMENT, 
  Name varchar(255) not null, 
  Birthday date not null, 
  PRIMARY KEY (ID) 
);

게시자 테이블은 동일한 패턴을 따릅니다. "NOT NULL"은 콘텐츠 없이 데이터가 추가되는 것을 방지하는 또 다른 제약 조건입니다.

CREATE TABLE Publishers ( 
  ID int NOT NULL AUTO_INCREMENT, 
  Name varchar(255) not null, 
  Address varchar(255) not null, 
  PRIMARY KEY (ID) 
);

books 테이블은 외래 키를 참조하므로 논리적이지만 이해하기가 약간 어렵습니다. 책 제목과 출판 날짜가 함께 기본 키를 형성한다는 점에 유의하세요.

CREATE TABLE Books ( 
   Name varchar(255) NOT NULL, 
   AuthorID int, PublisherID int, 
   PublishedDate date NOT NULL, 
   PRIMARY KEY (Name, PublishedDate), 
   FOREIGN KEY (AuthorID) REFERENCES Authors(ID), 
   FOREIGN KEY (PublisherID) REFERENCES Publishers(ID) 
);

상단의 깔끔한 테이블을 보려면 뷰가 필요 합니다 . 이는 스키마를 그대로 유지하면서 표시해야 하는 정보를 선택할 수 있도록 테이블을 함께 연결하는 방법일 뿐입니다. 이제 스키마가 기록되었으므로 뷰를 구축할 수 있습니다.

CREATE VIEW ViewableBooks AS 
SELECT Books.Name 'Book', Authors.Name 'Author', Publishers.Name 'Publisher', Books.PublishedDate 'Date' 
FROM Books, Publishers, Authors 
WHERE Books.AuthorID = Authors.ID 
AND Books.PublisherID = Publishers.ID;

데이터베이스를 설치할 필요가 없도록 온라인 놀이터에서 스키마를 생성할 수 있는지 살펴보겠습니다.

DB Fiddle이 그 일을 해야 합니다.

DDL을 입력한 후 실제 데이터를 추가하는 경우:

INSERT INTO Authors (Name, Birthday) 
VALUES ('Iain Banks', '1954-02-16'); 
 
INSERT INTO Authors (Name, Birthday) 
VALUES ('Iain M Banks', '1954-02-16'); 
 
INSERT INTO Publishers (Name, Address) 
VALUES ('Abacus', 'London'); 
 
INSERT INTO Publishers (Name, Address) 
VALUES ('Orbit', 'New York');

뷰를 본 결과는 DB Fiddle에 "Query 3"으로 표시되는데, 이는 정확히 우리가 보려는 데이터입니다.

LLM도 패턴을 만들 수 있나요?

자, 이제 LLM에게 스키마 생성에 대해 문의하고 싶습니다. LLM을 어떻게 안내할 것인지 요약하자면 다음과 같습니다.

영어로 스키마를 요청할 때 인덱스와 제약 조건을 포함하여 세 테이블에 대한 DDL을 생성하려고 합니다.
필요한 경우 제약 조건(기본 키, 외래 키 등)이 필요함을 암시할 수도 있습니다.
우리는 그것을 보도록 요청할 수 있습니다.
필요한 경우 MySQL 구문을 사용하도록 지시할 수 있습니다.

저는 Llama 3을 사용할 예정 이지만 OpenAI의 LLM도 살펴보았는데 거의 동일한 결과를 얻었습니다.

첫 번째 쿼리는 "책, 출판사, 저자를 설명하는 관계형 데이터베이스 스키마를 생성하세요."입니다.

결과:

여태까지는 그런대로 잘됐다. 아직 DDL을 생성하지 않았지만 별도로 요청할 수 있습니다. 어떻게든 영어로 패턴을 더 잘 설명할 수 있습니다. 나머지 답변을 살펴보겠습니다.

외래 키 제약 조건을 설명하고 예상하지 못한 ISBN을 추가합니다. 또한 "PublicationDate"는 "PublishedDate"보다 더 관용적입니다. 또한 테이블을 생성합니다.

이는 한 책에 대해 여러 저자를 생성하는 문제를 해결합니다. 이전에는 고려하지 않았던 문제입니다. 브리지 테이블이라는 용어는 두 테이블(도서 및 저자)이 외래 키로 결합되어 있음을 나타냅니다.

DDL에 "이 스키마에 대한 데이터 정의 언어를 보여주세요."라고 물어봅시다.

빈 항목이 없는지 확인하기 위해 NOT NULL을 포함하여 올바르게 반환됩니다. 또한 공급업체 SQL 간의 실제 차이로 인해 DDL이 어떤 측면에서는 "보편적"이라고 명시되어 있습니다.

마지막으로 뷰를 질문해 보겠습니다.

이것은 내 버전보다 더 복잡하지만 스키마 이름 지정을 조정하면 DB Fiddle에서 잘 작동합니다. 여기에 표시된 테이블 별칭 이름은 이해하는 데 도움이 되지 않습니다.

결론: LLM은 실제로 패턴을 만들 수 있습니다

LLM이 내 영어 설명을 잘 제한된 패턴으로 바꾼 다음 실행 가능한 DDL로 바꾸고 설명도 제공했기 때문에 이것이 LLM의 큰 승리라고 생각합니다(비록 이러한 설명은 더 기술적인 관계 세부 사항을 위한 것이 되었지만). 전용 LLM이나 서비스도 이용하지 않았는데 정말 잘 됐어요.

어떤 면에서 이는 한 도메인(출판 세계)을 다른 도메인(SQL의 도메인별 언어)으로 매핑하는 것이며 LLM의 이점이 매우 큽니다. 각 영역은 잘 정의되어 있고 세부 사항이 풍부합니다.

SQL의 생일을 축하합니다. LLM이 SQL의 관련성을 앞으로 수십 년 동안 유지하길 바랍니다!

이 기사는 Yunyunzhongsheng ( https://yylives.cc/ ) 에 처음 게재되었습니다 . 누구나 방문하실 수 있습니다.