# Relation-Aware Graph Transformer for SQL-to-Text Generation
## 1 Introduction  
SQL (Structured Query Language) is a vital tool to access databases. However, SQL is not easy to understand for the average person. SQL-to-text aims to convert a structured SQL program into a natural language description. It can help automatic SQL comment generation as well as build an interactive question answering system [1, 2] for natural language interface to a relational database [3, 4, 5]. Besides, SQL-to-text is useful for searching SQL programs available on the Internet. [PERSON] et al. [6] and [PERSON] et al. [7] also demonstrated that SQL-to-text can assist the text-to-SQL task [8, 9, 10, 11] by using SQL-to-text as data augmentation. In the real world, it can help people understand complex SQLs quickly by reading corresponding texts. A naive idea is casting SQL-to-text as a Seq2 Seq problem [12, 13]. Taking the SQL sequence as input, a Seq2 Seq model translates it to natural language. The main limitation is that when the SQL sequence becomes longer, the Seq2 Seq model may fail to capture the dependency between complex conditions and operations. SQL is structural and can be converted into an abstract syntax tree, as Figure 1 illustrated. Generally, a tree is a special graph, so SQL-to-text can be modeled as a Graph-to-Sequence [14] task. [PERSON] et al. [15] considers the intrinsic graph structure of a SQL query. They construct the SQL graph by representing each token in the SQL as a node in the graph, and concatenating different units (e.g., column names, operators, values) through SQL keyword nodes (e.g., SELECT, AND). By aggregating information from the \(K\)-hop neighbors through graph neural network ([PERSON], [PERSON] et al. [16], 2008), each node obtains its contextualized embedding which will be accessed in the natural language decoding phase. Though simple and effective, it suffers from two main drawbacks: (1) poor generalization capability due to the sparsity of the constructed SQL graph, and (2) ignorance of relations between different node pairs, especially the relevance among column nodes. In particular, [PERSON] et al. [15] only deals with the simple SQL sketch SELECT SAGG $COLUMN WHERE $COLUMN SOP SVALUE (AND $COLUMN SOP SVALUUE)*. Only one column unit and one single table are mentioned in the sketch, and all constraints are organized via intersections of conditions in the WHERE clause. The model updates the contextualized embedding of each node by a \(K\)-step iteration. Each node will only communicate with its 1-hop neighbors in one iteration, thus each node can only \"see\" nodes within the distance of \(K\) at the end of iterations. The performance will easily deteriorate when we transfer to more complicated SQL sketches composed of multiple tables, GroupBy/HAVING/OrderBy/LIMIT clauses and nested SQLs. As the example shown in Figure 1, a Graph2 Seq model with \(K=6\) may work well on the simple SQL (shown in the left) while generalizing poorly on the complex SQL with a longer dependency distance (shown in the right). We find that two nodes may share high correlations even though they are far apart in both the serialized SQL query and the parsed abstract syntax tree. For instance, the columns mentioned in the same clause (intra-clause) are tightly related. See the example in Figure 1b. Users always require not only the last name, but also the first name of specific candidates. Similarly, there is a high probability that the column serving as one condition in the WHERE clause will also be requested exactly in SELECT clause (inter-clause). Previous work pays more attention on the syntactic structure of SQL, but neglects these potential relations at the semantic level. To this end, we propose a Relation-aware Graph Transformer (RGT) to take into account both the abstract syntax tree of the query and the correlations between different node pairs. The entire node set is split into two parts: _intermediate nodes_ and _leaf nodes_. Leaf nodes are usually raw table names or column words, plus some unary modifiers such as DISTINCT and MAX.