Configuration Module for Treating Design Anomalies in Databases for a Natural Language Interface to Databases

Grigori Sidorov, Rodolfo A. Pazos R, José A. Martínez F, J. Martín Carpio, Alan G. Aguirre L

Research output: Chapter in Book/Report/Conference proceedingChapterpeer-review

Abstract

Natural language interfaces for databases (NLIDBs) are tools that allow obtaining information from a database (DB) through natural language queries. Currently, domain-independent NLIDBs (interfaces capable of working with several DBs) have not had a favorable performance due to the complexity for devising an approach that can solve all the problems that occur in NLIDBs. Another important problem is the existence of design anomalies in DBs, which have not been addressed in the approaches proposed by various authors. This chapter describes the implementation of a module for dealing with four design anomalies: absence of primary and foreign keys, use of surrogate keys, Columns for storing aggregate function calculations, and columns repeated in two or more tables. This module was implemented in an experimental NLIDB. The purpose of this is to allow the NLIDB to be configured so that it perceives an anomalous DB as a DB without design anomalies so the NLIDB can function correctly. Experimental tests of the NLIDB with the module for treating design anomalies show that it can correctly answer 100% of the test queries; whereas, the NLIDB without the module only generates 25% correct answers.

Original languageEnglish
Title of host publicationStudies in Computational Intelligence
PublisherSpringer
Pages703-714
Number of pages12
DOIs
StatePublished - 2020

Publication series

NameStudies in Computational Intelligence
Volume862
ISSN (Print)1860-949X
ISSN (Electronic)1860-9503

Keywords

  • Database anomaly
  • Database schema
  • Natural language interfaces to databases
  • Relational database

Fingerprint

Dive into the research topics of 'Configuration Module for Treating Design Anomalies in Databases for a Natural Language Interface to Databases'. Together they form a unique fingerprint.

Cite this