TRABAJO FIN DE GRADO Servicio de búsqueda inteligente para …oa.upm.es/55745/1/TFG_SALVADOR_GONZALEZ_GERPE.pdf · A su vez, existen varios tipos de consultas[2], realizadas en los

Graduado en Ingeniería Informática

Universidad Politécnica de Madrid

Escuela Técnica Superior deIngenieros Informáticos

TRABAJO FIN DE GRADO

Servicio de búsqueda inteligente para comercioelectronico

Autor: Salvador González GerpeDirector: Miguel García Remesal

MADRID, JUNIO DE 2019

ÍNDICE1. Introducción 1

1.1. Presentación del Trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3. Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2. Estado del Arte 32.1. Tecnológico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2. Sistemas Actuales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3. Diseño 133.1. Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.2. Solución propuesta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.3. Diseño de Alto Nivel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.3.1. Diagrama Entidad Relación . . . . . . . . . . . . . . . . . . . . 15

3.3.2. Casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.4. Diseño de Bajo Nivel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.4.1. Esquema de la Base de Datos Pre-Modificación . . . . . . . . . . 22

3.4.2. Esquema de la Base de Datos Post-Modificación . . . . . . . . . 27

3.4.3. Ejecución del servicio . . . . . . . . . . . . . . . . . . . . . . . 32

3.5. Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.5.1. Diagrama de Flujo . . . . . . . . . . . . . . . . . . . . . . . . . 33

4. Implementación 364.1. Fase de modificación del campo “description” . . . . . . . . . . . . . . . 36

4.2. Fase de lematización de tablas . . . . . . . . . . . . . . . . . . . . . . . 36

4.3. Fase de incorporación de índice “Full-Text” Index a las tablas lematizadas 37

4.4. Fase de creación de servicio web . . . . . . . . . . . . . . . . . . . . . . 38

4.5. Fase de creación de diccionarios de las tablas de unigrama para el uso del

modelo vectorial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.6. Fase de implementación de funciones y modelo vectorial TF-IDF en el

servicio web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.7. Fase de creación de cliente de pruebas . . . . . . . . . . . . . . . . . . . 43

4.8. Fase de implementación del servicio de autocompletado . . . . . . . . . . 44

4.9. Fase de implementación del filtro por número de resultados . . . . . . . . 44

5. Pruebas y Resultados 465.1. Prueba 1: Una palabra. . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.2. Prueba 2: Dos palabras. . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.3. Prueba 3: Tres palabras. . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.4. Prueba 4: Cuatro palabras o más. . . . . . . . . . . . . . . . . . . . . . . 48

5.5. Prueba 5: Búsqueda errónea. . . . . . . . . . . . . . . . . . . . . . . . . 49

5.6. Prueba 6: Búsqueda de un elemento mal escrito. . . . . . . . . . . . . . . 49

I

5.7. Prueba 7: Búsqueda de un elemento que no se encuentra dentro de la base

de datos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

5.8. Prueba 8: Búsqueda de palabras con caracteres UTF-8. . . . . . . . . . . 50

5.9. Prueba 9: Búsqueda de elemento limitando resultados en 5 elementos. . . 51

5.10. Prueba 10: Muestra de sistema de autocompletado. . . . . . . . . . . . . 51

5.11. Prueba 11: Búsqueda de elementos en distinto orden. . . . . . . . . . . . 52

5.12. Prueba 12: Búsqueda con una palabra (Error con devolución de elemento) 53

6. Discusión 54

7. Conclusiones 55

II

ÍNDICE DE FIGURAS1. Ejemplo Lematización . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2. Modelo Vectorial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3. Magento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

4. PrestaShop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

5. OpenCart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

6. Sphinx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

7. Apache Solr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

8. ElasticSearch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

9. Diagrama de Entidad Relación . . . . . . . . . . . . . . . . . . . . . . . 15

10. Modelo Entidad Relación de la Base de Datos Inicial . . . . . . . . . . . 22

11. Modelo Entidad Relación de la Base de Datos Inicial . . . . . . . . . . . 27

12. Diagrama de Ejecución del Servicio . . . . . . . . . . . . . . . . . . . . 33

13. Diagrama de Flujo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

14. Prueba 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

15. Prueba 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

16. Prueba 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

17. Prueba 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

18. Prueba 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

19. Prueba 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

20. Prueba 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

21. Prueba 8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

22. Prueba 9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

23. Prueba 10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

24. Prueba 11.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

25. Prueba 11.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

26. Prueba 12.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

27. Prueba 12.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

ÍNDICE DE CUADROS1. Plantilla Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2. Caso 1 (Una palabra) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3. Caso 2 (Dos palabras) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4. Caso 3 (Tres palabras) . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

5. Caso 4 (4 palabras o más) . . . . . . . . . . . . . . . . . . . . . . . . . . 19

6. Caso 5 (Búsqueda de elementos que no existen dentro de la base de datos) 20

7. Caso 6 (Equivocación a la hora de escribir búsqueda) . . . . . . . . . . . 21

8. Tabla 1: product . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

9. Tabla 2: product_description . . . . . . . . . . . . . . . . . . . . . . . . 24

10. Tabla 3: related_entity . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

11. Tabla 4: characteristic . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

III

12. Tabla 5: product_related_entity . . . . . . . . . . . . . . . . . . . . . . . 25

13. Tabla 6: product_characteristic . . . . . . . . . . . . . . . . . . . . . . . 26

14. Tabla 1: product_description_index1 . . . . . . . . . . . . . . . . . . . . 28




18. Tabla 5: related_entity_index1 . . . . . . . . . . . . . . . . . . . . . . . 29




22. Tabla 9: characteristic_index1 . . . . . . . . . . . . . . . . . . . . . . . 31




IV

Resumen

En este proyecto se presenta un servicio de búsqueda web basado en texto

capaz de realizar la búsqueda de un recurso almacenado en una base de datos.

Este servicio funciona mediante la lematización de términos realizando una

búsqueda prácticamente exacta. Los recursos obtenidos son resultado de un

proceso de filtrado mediante un modelo vectorial (TF-IDF) con umbral defi-

nido. Se ha implementado el motor de búsqueda en forma de servicio web.

Además se ha implementado un cliente con el fin de probar el servicio de

búqueda web. Los resultados parecen ser adecuados para la tarea propuesta.

Palabras clave: motor de búsqueda, servicio web, comercio electróni-

co. . .

Abstract

In this project, a text-based search engine is presented. It is capable of

searching for resources stored in a database. This service works through the

stemmization of terms, carrying out a practically exact search. The resources

retrieved are the result of a filtering process using a vectorial model (TF-IDF)

with a defined threshold. In this work, the search engine is implemented as a

web service. A client is also implemented as an evaluation platform for the

tool. The results obtained show a suitability of the platform for the proposed

task.

Keywords: search engine, web service, electronic commerce. . .

V

1. INTRODUCCIÓN

1.1. Presentación del TrabajoEl comercio electrónico sigue creciendo, cada vez son más las empresas que deciden

abrir un negocio buscando la rentabilidad y posibilidades que este ofrece frente a los co-

mercios tradicionales.

“Si tu negocio no está en Internet, tu negocio no existe.” Bill Gates

El mercado electrónico ha demostrado ser la alternativa perfecta para el comercio,

debido a que nos proporciona ventajas como la venta al público abierta 24 horas los 365

días del año, además de ofrecer acceso desde cualquier parte del mundo, el aumento de la

gama de productos, ofertarse a nivel internacional a bajos costes y la capacidad de proce-

sar gran cantidad de pedidos de forma instantánea, entre otras muchas utilidades.

La rivalidad en la red, es una realidad que afecta a todos los comercios electrónicos,

siendo una de las mayores competencias la disponibilidad de una página web capaz de

satisfacer todas las necesidades que el usuario que la utilice disponga.

“El comercio electrónico será un amplio sector en el que triunfarán numerosas em-presas al mimso tiempo con estrategias diferentes. Aquí no hay sitio para diez o cienempresas, sino para decenas o miles de empresas.” Jeff Bezos

Poseer un comercio dominante en el mercado electrónico implica la posesión de una

página vez que facilite el acceso directo a la compra de los productos ofrecidos por dicho

comercio. La web debe satisfacer unos determinados aspectos que la hagan resaltar entre

el resto de la competencia. Para ello, la visualización, organización y la intuitividad son

esenciales para proporcionar un acceso abierto para cualquier usuario dentro del servicio

web.

Existen numerosos comercios electrónicos destinados al mundo musical, destacando

la compra-venta de instrumentos musicales. De entre todos ellos, una empresa pertene-

ciente a dicho ámbito, ha tenido la necesidad de realizar un motor de búsqueda para su

página web.

Con el objetivo de que dicho buscador cumpla con determinados requisitos, y que a

su vez consiga sufragar las demandas de los usuarios que lo utilicen, se nos ha encon-

mendado realizar dicho motor de búsqueda, con el fin de que puedan implementarlo en su

servicio web y usarlo.

1

1.2. MotivaciónTras un exhaustivo estudio cuya finalidad era observar el comportamiento de los bus-

cadores de distintas páginas web relativas al comercio electrónico, hemos observado que

cuentan con buscadores que no son del todo certeros, es decir, a la hora de buscar no en-

cuentran de forma concreta aquello que el ussuario desea encontrar.

La existencia de varias empresar que se dedican al comercio electrónico hace posi-

ble una elevada competitividad dentro del sector. Por ello, es necesario realizar este tipo

de buscadores, cuya finalidad es que dichas empresas lo instalen en su plataforma y dis-

pongan de un mejor motor de búsqueda de sus productos, haciendo que el servicio web

destaque sobre otros.

1.3. ObjetivoEl objetivo consiste en la realización de un sistema buscador, que se encargue median-

te la lematización de los parámetros introducidos en la barra de búsqueda y un modelo

vectorial de TF-IDF, para conseguir obtener todos los elementos correspondientes que se

quieren buscar. Un ejemplo de esto, sería introducir en la barra de búsqueda dos paráme-

tros, como por ejemplo “Guitarra Roja”, y que mediante la lematización de la primera y

de la segunda palabra, consiguiese sacar por la pantalla del servicio web, los resultados

más acertados a la búsqueda, que en este caso serían todas las guitarras de color rojo que

se encuentren almacenadas en la base de datos.

Lo importante de este sistema, es la capacidad de poder buscar todo elemento del cual

se tenga un interés, en este caso objetos pertenecientes al ámbito de la música, con mayor

eficacia que tener que buscarlo a mano y con el fin de poder conseguir el objetivo, que en

este caso es encontrar el objeto/elemento solicitado, de una forma más eficiente y rápida.

El problema existente en los búscadores que poseen hoy en día las páginas web per-

tenecientes a tiendas dedicadas al ámbito de la música, es que emplean buscadores de

elementos, centrándose solo en el término como tal, es decir, un ejemplo de esto sería

buscar el término “Guitarro” en la barra de búsqueda, pero el buscador, al está solo codi-

ficado con la búsqueda de la palabra del elemento como tal, no sería capaz de obtener, en

ningún caso, todas las “Guitarras” o elementos relacionados, por lo que, o no te devuelve

ningún resultado, o te devuelve resultados que son erróneos.

Este problema anteriormente mencionado, se puede solvetar utilizando un sistema de

lematización que es el que se va a incluir en este trabajo. Dicho sistema de lematización

extrae el lexema perteneciente a cada una de las palabras introducidas por la barra de

búsqueda del servicio web, y a partir de él, busca todos los elementos que lo contienen en

la formación de su palabra, y los saca por pantalla. Un ejemplo de esto, sería la búsqueda

de la palabra “Guitarro”, y al lematizarse dicha palabra en el lexema “Guitarr”, sería capaz

2

de encontrar todos los elementos que en su palabra contengan el lexema descrito, y así

sacar por pantalla todos los elementos que pertenezcan a la familia léxica de “Guitarro”.

2. ESTADO DEL ARTE

2.1. TecnológicoUn buscador o motor de búsqueda[1] se trata de un método interactivo, utilizado

para buscar en una base de datos datos que el usuario que está usando la aplicación quiere

obtener, adquiriendo resultados exactos sobre su búsqueda.

El método que es llevado a cabo pasa por varias fases, de entre las cuales destacan,

en primer lugar, el análisis de los criterios de búsqueda, en segundo lugar, mediante dicho

analisis de los criterios, se realiza dicha búsqueda en la base de datos indicada, obteniendo

un conjunto de resultados inicial, los cuales en tercer lugar, se contrastan con la entrada

que ha dado el usuario y así, en cuarto y último lugar, dar una salida de los resultados más

exactos a la búsqueda.

A su vez, existen varios tipos de consultas[2], realizadas en los motores de búsqueda,

las cuales son consultas de tipo relativo a la navegación, consultas de tipo informativo y

consultas de tipo transaccional.

Por otro lado, existen vario tipos de buscadores, de entre los cuales destaca el motor

de búsqueda denominado como metabuscador[3]. Dicho buscador se encarga de reenviar

consultas, recibidas a traves de sus propios parámetros, a otros motores de búsqueda, con

el fin de poder analizar la información obtenida a partir de estos y extraer la información

que contienen dichas consultas, ubicando los términos de dicha consulta en los documen-

tos de los cuales se ha extraido la información.

Además de existir el metabuscador, los buscadores se diferencian en tres característi-

cas[4], las cuales son las siguientes:

En primer lugar, se encuentran los motores de búsqueda basados en rastreadores(“Crawler-Based Search Engines”), como por ejemplo Google, que se encargan de ras-

trean información en la web y posteriormente los usuarios buscan a través de lo que el

propio motor de búsqueda ha encontrado.

En segundo lugar, se encuentran los motores de búsqueda basados en directoriosaccionados por el hombre (“Human-Powered Directories”), como por ejemplo Open

Directory, que dependen de los humanos para formar sus listados, es decir, un usuario

envía una breve descripción del directorio de todo el sitio, o los editores se encargan de

escribir una descripción para los sitios que revisan. De esta forma, una búsqueda funciona

encontrando coincidencias solo entre las descripciones que han sido enviadas.

3

En tercer y último lugar, se encuentran los motores de búsqueda híbridos (“HybridSearch Engines”), que funciona con la unión de los dos tipos de motores de búsqueda

anteriores.

Para poder realizar dichos tipos de motores de búsqueda, se deberán de programar

en diferentes tipos de lenguajes, siendo en este caso, los lenguajes de programación de

Python y SQL.

En primer lugar, el lenguaje Python [5] se trata de un lenguaje de alto nivel, cu-

ya filisofía de diseño enfatiza en la legibilidad del código. Dicho lenguaje permite a los

programadores expresar conceptos en menos líneas de código de lo que sería posible en

lenguajes como C. A su vez, el lenguaje proporciona construcciones destinadas a permitir

programas claros tanto a pequeña como a gran escala.

En segundo lugar, el lenguaje SQL [6] que se trata de un sublenguaje de base de datos

relacional. No es un lenguaje de programación completo, pero depende de la E/S y control

de las instalaciones de un lenguaje de acogida.

Una base de datos [7], son el método por excelencia para el almacenamiento estruc-

turado de datos. Desde las aplicaciones de multiusuario hasta los números de telefono o

agendas telefónicas utilizan el sistema de las bases de datos ya que aseguran la integridad

de los datos y facilitan el trabajo tanto de los usuario como de los programadores que lo

desarrollaron.

Con el fin de poder conectar las bases de datos con el lenguaje Pyhton con el fin de

poder procesar los datos, se utiliza una biblioteca denominada PyMySQL [8], que me-

diante numerosas funciones que contiene, se obtiene la conexión de la base de datos con

cualquier script en Python pudiendo manipular los datos pertenecientes a la base de datos

desde el propio programa.

Con el objetivo de que el motor de búsqueda consiga mejores resultados en su eje-

cución, se van a utilizar las técnicas de lematización[9]1, que consiste en asignar una

forma representativa a distintas formas concretas variables, como pueden ser las formas

conjugadas de un verbo, el número de sustantivos y adjetivos, cambios en el género, etc.

A partir de estas técnicas de lematización, se sacan los lexemas o raíces, pertenecientes a

las palabras, que son el conjunto de letras que contienen en el mismo orden, palabras que

pertenecen a su familia léxica.

4

Figura 1: Ejemplo Lematización

Para poder realizar la lematización, deberemos de utilizar una serie de bibliotecas per-

tenecientes a NLP[10] (“Natural Processing Language”).

El término de NLP abarca un amplio conjunto de técnicas destinadas a la generación

automatizada, con el fin de poder manipular y analizar tanto el lenguaje natura como el

idioma de los humanos. Por otro lado cabe destacar que la mayoría de las técnicas de NLP

son heredadas por parte de la Lingüística y de la Inteligencia Artificial, que a su vez, estas

están influenciadas por áreas más nuevas como pueden ser el Aprendizaje Automático

(“Machine Learning”), la Estadística Computacional (“Computational Statistics”) y la

Ciencia Cognitiva (“Cognitive Science”).

Una de las bibliotecas por excelencia que contiene NLP es NLTK [10], que a su vez

es de la que vamos a utilizar varias de sus funciones para poder realizar la lematización

de las palabras.

El biblioteca de NLTK es una colección de módulos, lanzada desde una licencia de código

abierto, que permite a los estudiantes aprender y realizar investigaciones en NLP. La ven-

taja más importante de usar la biblioteca de NLTK es que es totalmente autocontenido. No

solo proporciona funciones y envoltorios convenientes que se pueden usar como bloques

de construcción para tareas comunes de NLP, sino que también proporciona versiones en

bruto y preprocesadas utilizadas en la literatura de NLP y cursos.

Dentro de la biblioteca de NLTK, vamos a utilizar la función de SnowballStemmer[11], que se trata de una interfaz de procesamiento para eliminar los afijos morfológicos

de las palabras, conociendo este proceso como derivación. De esta forma conseguiremos

sacar los lexemas o raíces de todas las palabras que se quieran lematizar.

En algunos de los campos pertenecientes a la base de datos que se deben de lematizar,

se encuentran en formato HTML [12], que es el lenguaje utilizado por la World Wide

Web (www) y que permite a los usuarios publicar documentos en línea, recuperar infor-

mación, diseñar formularios para realizar transacciones con servicios remotos para usar

en la búsqueda de la información, etc.

La existencia de dichos datos en HTML, hacen que no se puedan lematizar, por ello se

utiliza una biblioteca de BeautifulSoup4[13], con el objetivo de pasar los datos que se

5

encuentran en HTML a formato texto y poder lematizarlos.

BeautifulSoup4 es una biblioteca de Python que tiene la función de extraer datos de

archivos HTML y XML.

Antes de poder realizar el motor de búqueda, es necesario disponer de un servicioweb con el que buscar datos pertenecientes a sus bases de datos.

Un servicio web es una aplicación de software indentificada por una URI, cuyas inter-

faces y enlaces son capaces de ser definidos, descritos y descubiertos como datos XML.

A su vez, un servicio web admite interacciones directas con otros agentes del software

utilizando mensajes basados en XML intercambiados a través de protocolos basados en

Internet.

Para poder disponer de dicho servicio web, utilizaremos la herramienta de Django,

construida sobre Python, con el fin de crear un servicio web donde establecer el buscador.

La herramienta de Django [14], es una combinación de herramientas pertenecientes al

lenguaje de Python que fomenta el desarrollo rápido y, el diseño limpio y pragmático.

Con el fin de poder sincronizar el servicio web con los programas en python y las

bases de datos, se utilizan sentencias codificadas en formato JSON.

JSON [15] (“JavaScript Object Notation”), es un formato de intercambio de datos

ligero basado en texto independiente del idioma. Se derivó del estándar del lenguaje de

programación ECMAScript. A su vez, define un pequeño conjunto de reglas de formato

para la representación portátil de datos estructurados.

Con el objetivo de poder obtener una lista de resultados más precisos en la búsque-

da, se utiliza el modelo vectorial “TF-IDF’’[16] (term frequency and inverse term fre-quency)

La definición de TF (tern frequency) consiste en que el valor o peso, de un término kique aparece en un documento dj es simplemente proporcional al término frecuencia fi,j ,es decir, cuanto más a menudo aparece un término ki en el texto del documento dj , mayor

es el peso de la frecuencia del término TFi,j . A su vez, la variante del peso TF utilizada

en la literatura es la siguiente:

tfi,j =

{1 + log2fi,j iffi,j > 0

0 en otro caso

Por otro lado, nos encontramos con dos definiciones para IDF (inverse term fre-quency), una perteneciente a exhaustividad y especificidad y la otra a exhaustividad ópti-

6

ma.

En primer lugar, se va a explicar la definición de exhaustividad y especifidad, siendo la

exhaustividad una propiedad de las descripciones de los documentos y la especificidad la

propiedad de los términos de índice. La exhaustividad de la descripción de un documento

se interpreta como la cobertura que proporciona para los temas principales del documen-

to. La especificidad de un término con índice índice se interpreta observando como de

bien el término describe un tema perteneciente al documento.

En segundo lugar, se va a explicar la definición perteneciente a la exahustividad ópti-

ma. Cuantos más términos con índice asigne a un documento, más exhaustiva será su des-

cripción. Su probabilidad de recuperación por una consulta seleccionada aleatoriamente

de la secuencia de consulta también aumenta. Sin embargo, si se asignan demasiados tér-

minos a un documento, éste se recuperará mediante consultas para las que no es relevante.

Esto sugiere que el número promedio de términos con índice por documento debería ser

óptimo de manera que se maximice la probabilidad de relevancia de un documento recu-

perado. Este número óptimo de términos con índice define la exhaustividad óptima para

las descripciones de ese documento. A su vez, la variante del peso IDF utilizada en la

literatura es la siguiente:

IDFi = log2N

ni

Una vez se han explicado los dos por separados, se va a explicar la definición existente

entre ambos pesos, denominandose como “Ponderación de TF-IDF” y definiéndose de

la siguiente forma:

wi,j =

{(1 + log2fi,j) ∗ log2 N

niiffi,j > 0

0 en otro caso

Debido a dicha definición, TF e IDF se formulan de la siguiente forma:

TFi = 1 + logN∑j=1

fi,j

IDFi = log

(N

ni

)

A su vez, hay que tener en cuenta la normalización de la longitud del documento, que

se define en las tres tipos de representaciones, es decir, en tamaño en bytes, número de

palabras y normas de vectores.

7

En primer lugar, se va a explicar la representación en tamaño en bytes. Como inicio

cabe destacar que cada documento se representa como un flujo de bytes. En este caso, la

longitud del documento es el número de bytes del flujo, es decir, el tamaño en bytes del

documento. La ventaja clave de esta representación es su simplicidad.

En segundo lugar, se va a explicar la representación en número de palabras. Como

inicio cabe destacar que cada documento se representa como una sola cadena, que puede

descomponerse en sus palabras que lo consituyen. En este caso, la longitud del documento

es el número de palabras que contiene. Esta representación es también simple pero calcula

la longitud de los documentos a nivel sintáctico, que incluye más semántica.

En tercer lugar, se va a explicar la representación en normas de vectores. Como inicio

cabe destacar que cada término está asociado con un vector unitario ortonormal �ki en un

espacio t-dimensional. En este espacio, los documentos pueden ser representados como

vectores de términos ponderados de la siguiente manera. Con el término ki del documento

dj se asocia el vector wi,j ∗ �ki que representa la contribución del término al documento.

El �dj de representación de documentos se convierte en el vector compuesto por todos

sus componentes vectoriales. La longitud del documento viene dada por la norma de este

vector, que se computa de la siguiente forma:

|�di| =√√√√ t∑

i

w2i,j

Además de lo explicado anteriormente, se encuentra el modelo vectorial, que se define

como que el peso wi,j asociado con un par de documento de término (ki, dj) es no negativo

y no binario. Se supone que todos los términos con índice son mutuamente independientes

y se representan como vectores unitarios de un espacio t-dimensional, en dj y query q son

vectores t-dimensionales dados por:

�di = (w1, w2, ..., wt,j)

�q = (w1,q, w2,q, ..., wt,q)

Por lo tanto se obtiene el siguiente gráfico 2, donde el coseno del ángulo θ es el

resultado entre el vector �q y el vector �dj:

8

Figura 2: Modelo vectorial

La fórmula del coseno utilizada es la siguiente:

cos(θ) =�q ∗ �d

‖�q‖‖�d‖ =

∑ni=1 �qi ∗ �di√∑n

i=1(�qi)2 ∗

√∑ni=1(

�di)2

Con el fin de poder realizar dicho modelo vectorial, son necesarias las bilbiotecas

pertenecientes a gensim, en específico a las funciones de corpora[17] que contienen los

procesos para realizar dicho modelo vectorial. Gensim es una biblioteca Python que lucha

en dos frentes:

1. Indexación de documentos digitales y búsqueda de similitudes.

2. Rapidez, algoritmos escalables y eficientes en términos de memoria para la des-

composición de valor singular y la asignación latente de dirichlets.

La conexión entre los dos es el análisis semántico no supervisado de texto sin formato

en colecciones digitales

Por último, para poder realizar el cliente que se encargue de poder probar el servicio

web de búsqueda, se utiliza el lenguaje de JavaScript, principalmente JQuery[18]

JQuery es un framework Javascript,que sirve como base para la programación avanza-

da de aplicaciones, que aportauna serie de funciones o códigos para realizar tareas habi-

tuales. Por decirlo de otra manera, framework son unas librerías de código que contienen

procesos o rutinas ya listos para usar.

9

2.2. Sistemas ActualesActualmente, existen gran varierdad de motores de búsqueda, como hemos explicado

en el punto anterior, con el fin de que los comercios puedan introducirlos en sus platafor-

mas web, con el objetivo de cumplir todas las demandas de los usuarios de forma rápida

y eficaz.

Por un lado, la mayor parte de las plataformas que ofrecen motores de búsqueda a va-

rios servicios web destinadas al comercio electrónico, no realizan una búsqueda a través

de sistemas complejos como pueden ser la lematización de los términos para realizar una

búsqueda más óptima.

A continuación se van a nombrar varias de las plataformas que no ofrecen un motor de

búsqueda que ofrecen un resultados que no se acercan correctamente a la búsqueda de los

productos que se ha querido realizar.

En primer lugar, se encuentra la plataforma de Magento[19]3, que es una platafor-

ma de código abierto y arquitectura modular para comercio electrónico ofreciendo una

gran felxibilidad y control sobre la página. Las características más importantes son la

capacidad de generar y administrar múltiples servicios web desde solo un panel de admi-

nistración.

Figura 3: Logo Magento

En segundo lugar, nos encontramos con una de las plataformas que rivalizan con Ma-

gento, denominada como Prestashop[19]4.

Prestashop se trata de un software de código abierto para el comercio electrónico

desarrollado en PHP y MSLQ encontrándose disponible de forma gratuita bajo licencia

de “Open software”. A su vez, se encuentra disponible en 38 diferentes idiomas inclu-

yendo el español. También incluye más de 260 funcionalidades que permiten vender tanto

productos físicos como descargables, clasificar los productos por diferentes criterios, ges-

tionar ofertas y descuentos, importar ficheros CSV, etc.

10

Figura 4: Logo PrestaShop

Además de estos dos softwares de código abierto anteriores, se encuentra el software

OpenCart[19]5, que es uno de los softwares más sencillos e intuitivos para el comercio

electrónico. Se trata de una plataforma de código abierto destinada a pequeños y media-

nos negocios que requieran de una herramienta flexible y personalizable sin excesivas

complicaciones técnicas. Las funciones que ofrece son permitir añadir de forma ilimitada

cuantos productos, páginas, fabricantes y categorías deseemos. A su vez genera páginas

optimizadas para el uso de motores de búsqueda.

Figura 5: Logo OpenCart

Por otro lado, después de estas plataformas, se encuentran los mejores servicios de

búsqueda para el comercio electrónico.

En primer lugar, nos encontramos con el motor de búsqueda Sphinx[20]6, que se

trata de un conjunto de herramientas en escritas en el lenguaje de programación de Ja-

va y un entorno interactivo para buscadores web. A diferencia de otros desarrolladores

de motores de búsqueda, Sphinx se encentra orientado a desarrollar buscadores que son

especificos para un servicio web, permitiendo personalizarlos y reubicarlos. A su vez, per-

mite encapsular y reutilizar las reglas de búsqueda específicas para el servicio web en los

analizadores de contenido, conocidos como clasificadores. Otra función que desempeña,

es que para una mayor eficiencia, los buscadores reubicables desarrollados con Sphinx,

se pueden tanto cargar como ejecutar en un servidor remoto.

11

Figura 6: Logo Sphinx

En segundo lugar, nos encontramos con uno de los motores de búsqueda más impor-

tantes del mercado, denominado como ApacheSolr o Apache Lucene[21]7, que se trata

de una biblioteca de búsqueda de código abierto basada en Java, que proporcina inter-

faces de programación de aplicaciones para realizar tareas comunes de búsqueda, como

la indexación, resaltado de consultas, análisis de idiomas y muchas otras más funciones.

Alcualmente es utilizado en servicios web como Twitter e Instagram, en su version 4.0.

Figura 7: Logo Apache Solr

En tercer y último lugar, se encuentra el motor de búsqueda más importante hasta la

fecha, denominado como ElasticSearch[22]8, el cual actualmente rivaliza con el motor

de búsqueda proporcionado por ApacheSolr. Este software, está basado en la biblioteca

Lucene al igual que ApacheSolr. A su vez, proporciona un motor de búsqueda de texto

completo, de código abierto, y de distribución en varios servidores, con el fin de poder

buscar todo tipo de documentos. Proporciona una búsqueda escalable, en tiempo real y

soportando como se ha dicho anteriormente, ejecutarlo en varios servidores a la vez. Este

tipo de buscador se usa en empresas como Ebay, VW, IEEE y Netflix.

12

Figura 8: Logo ElasticSearch

3. DISEÑO

3.1. RequisitosLos requisitos que se han tenido en cuenta en el momento de realizar el proyecto han

sido los siguientes:

1. Se debe de realizar un buscador que sea capaz de que mediante un input, devolver

outputs que correspondan con los resultados esperados, es decir, una vez introduci-

dos los elementos, el servicio debe de devolver los resultados más similares que se

encuentren dentro de la base de datos proporcionada.

2. El servicio debe de poder admitir y tratar caracteres pertenecientes a UTF-8, tales

como tildes o símbolos que no se usan comúnmente, como puede ser ’ñ’.

3. El servicio debe de ser capaz de poder preprocesar y analizar todo tipo de texto que

se de como input con el objetivo de conseguir realizar la búsqueda.

4. El servicio debe de recibir los datos recibidos como input en formato JSON y debe

de ser capaz de tratarlo.

5. El servicio debe de devolver como output un diccionario de JSON, conteniendo

cada uno de ellos una respuesta a la consulta previamente realizada.

6. El servicio debe de ser capaz de navegar por la base de datos proporcionada de

forma ágil.

7. El modelo de búsqueda será basado en palabras o expresiones lematizadas.

8. Los datos que se encuentren dentro de la base de datos deben de ser separados en

tablas de índices y lematizados con el formato de n-gramas, estando estos contem-

plados dentro del rango de 1 a 4 (incluyendo a ambos).

9. El servicio debe de ser capaz de utilizar un modelo vectorial.

13

10. El modelo vectorial que debe de utilizar dicho servicio tiene ser el modelo de TF e

IDF para realizar la búsqueda de los elementos.

11. Disponer de un diccionario de vectores para cada tabla lematizada de uni-grama

con el fin de poder realizar el modelo vectorial.

11. El servicio debe de proporcionar una búsqueda en la que el orden de las palabras

pertenecientes al texto introducido como input debe resultar en búsquedas equiva-

lentes.

12. El servicio debe de dar soporte al cliente con un autocompletado con sugerencias.

3.2. Solución propuestaLa solución propuesta para realizar el trabajo es la siguiente:

En primer lugar, el servicio debe de poder recibir los datos pertenecientes a la solici-

tud de búsqueda encapsulados dentro de un json.

En segundo lugar una vez hemos obtenido los datos, por un lado obtenemos los identi-

ficadores de los porductos existentes dentro de las tablas pertenecientes a la base de datos

que posean un mayor acierto en cuanto a la similitud con los datos de la búsqueda, a partir

del modelo vectorial. Por otro lado, se realiza la lematización de la búsqueda por tamaño

de n-grama desde 1 hasta 4.

En tercer lugar, se realiza una búsqueda a la base de datos con los identificadores obte-

nidos a partir del modelo vectorial, utilizándolos como límite de búsqueda, y los n-gramas

pertenecientes a los datos de la búsqueda.

En cuarto lugar, obteniendo los datos que ha devuelto la base de datos después de la

llamada, se encapsulan dentro de json y posteriormente estos json guardados dentro de

un diccionario, creando un diccionario de json que va a ser el que se le va a devolver al

cliente para que el usuario pueda observar los resultados a su búsqueda.

14

3.3. Diseño de Alto Nivel3.3.1. Diagrama Entidad Relación

Figura 9: Diagrama de Entidad Relación

Usuario: persona que utiliza el servicio web.

Servicio Web: servicio desarrollado en este proyecto que se encarga de realizar

búsquedas dentro de una base de datos mediante técnicas de lematización y modelos

vectoriales.

Base de Datos: lugar donde se encuentran almacenados todos los datos relativos a

los productos.

Búsqueda: herramienta para encontrar lo deseado por el usuario.

3.3.2. Casos de uso

Para los casos de uso que se van a explicar a continuación, se tiene en consideración

que se usa un cliente web capaz de enviar y recivir los datos de la búsqueda en formato

JSON.

(A parte de realizar el servicio web de búsqueda, se ha realizado un pequeño cliente web

15

ID Caso de Uso Nombre

Descripción Acción que se quiere llevar a cabo

Procesos Realizados Procesos que se han llevado a cabo para llegar a la solución

Salida Correcta Solución correcta a la solicitud de búsqueda

Estado Sistema Pre-Uso Disposición del sistema antes de su uso

Estado Sistema Post-Uso Disposición del sistema después de su uso

Cuadro 1: Plantilla Casos de Uso

capaz de poder alcanzar los objetivos del servicio web, con el fin de poder utilizarlo.)

A su vez, para poder representar los casos de uso se utilizará la siguiente plantilla:

Caso de uso 1

CU01 Una palabra

Descripción El usuario realiza una búsqueda en el servicio web con el tama-

ño de una sola palabra.

Procesos Realizados 1. El usuario introduce la palabra que quiere buscar dentro de

la barra de búsqueda.

2. El servidor recibe la palabra en formato Json y la preprocesa

realizando el proceso de lematización (obteniendo 1 unigrama),

y a su vez realiza el proceso llevado a cabo por el modelo de

vectorización TF-IDF.

3. Se realiza la búsqueda con los identificadores obtenidos en el

modelo de vectorización y la palabra lematizada, sobre la tabla

donde se ecuentran los datos de los productos lematizadas en

unigramas.

4. Se devuelve como diccionario de Json y se muestran los re-

sultados al usuario.

Salida Correcta Resultados que contengan la raíz léxica de la palabra introduci-

da como parámetro de búsqueda.

Estado Sistema Pre-Uso Barra de búsqueda vacía.

Estado Sistema Post-Uso Barra de búsqueda vacía y resultados representados en pantalla.

Cuadro 2: Caso 1 (Una palabra)

16

Caso de uso 2

CU02 Dos palabras


ño de dos palabras.

Procesos Realizados 1. El usuario introduce las palabras que quiere buscar dentro de



realizando el proceso de lematización (obteniendo 1 digrama y

dos unigramas), y a su vez realiza el proceso llevado a cabo por

el modelo de vectorización TF-IDF

3. Se realiza la búsqueda con los identificadores obtenidos en

el modelo de vectorización y las palabras lematizadas, sobre las

tablas donde se ecuentran los datos de los productos lematiza-

das en unigramas (en el caso de los unigramas obtenidos en el

proceso de lematización) y en digramas (en el caso de los di-

gramas obtenidos también).



Salida Correcta Resultados que contengan la raíz léxica de las palabras intro-

ducidas como parámetro de búsqueda indiferentemente de la

posición en la que se hayan introducido.



Cuadro 3: Caso 2 (Dos palabras)

17

Caso de uso 3

CU03 Tres palabras


ño de tres palabras.




realizando el proceso de lematización (obteniendo 1 trigrama

y dos digramas y tres trigramas), y a su vez realiza el proceso

llevado a cabo por el modelo de vectorización TF-IDF


modelo de vectorización y la palabras lematizadas, sobre las ta-

blas donde se ecuentran los datos de los productos lematizadas

en unigramas (en el caso de los unigramas obtenidos en el pro-

ceso de lematización), en digramas (en el caso de los digramas

obtenidos también) y en trigramas(en el caso de los trigramas

obtenidos también).








Cuadro 4: Caso 3 (Tres palabras)

18

Caso de uso 4

CU04 4 palabras o más

Descripción El usuario realiza una búsqueda en el servicio web con el ta-

maño de cuatro palabras. (Y resto de los casos en los que se

utilicen más de cuatro palabras).




realizando el proceso de lematización (obteniendo 1 tetragrama

y dos trigramas y tres diigramas y cuatro unigramas; en el caso

de más de 4 palabras aumenta cada número en 1), y a su vez

realiza el proceso llevado a cabo por el modelo de vectoriza-

ción TF-IDF






obtenidos también), en trigramas(en el caso de los trigramas

obtenidos también) y en tetragramas(en el caso de los tetragra-

mas obtenidos).








Cuadro 5: Caso 4 (4 palabras o más)

19

Caso de uso 5

CU05 Búsqueda de elementos que no existen dentro de la base de datos

Descripción El usuario realiza una búsqueda en el servicio web de un ele-

mento que no existe dentro de la base de datos








ción TF-IDF






obtenidos también), en trigramas(en el caso de los trigramas ob-

tenidos también) y en tetragramas(en el caso de los tetragramas

obtenidos), pero al no encontrar nada devuelve una lista vacía.

Salida Correcta Se devuelve un mensaje que dice que no existen resultados.


Estado Sistema Post-Uso Barra de búsqueda vacía y un mensaje indicando que no hay

resultados.

Cuadro 6: Caso 5 (Búsqueda de elementos que no existen dentro de la base de datos)

20

Caso de uso 6

CU06 Equivocación a la hora de escribir búsqueda

Descripción El usuario realiza una búsqueda en el servicio web de un ele-

mento y lo escribe mal








ción TF-IDF






obtenidos también), en trigramas(en el caso de los trigramas

obtenidos también) y en tetragramas(en el caso de los tetragra-

mas obtenidos), si la raíz lexica de la palabra mal escrita existe

en la base de datos, devolverá dichos resultados. En el caso de

que no exista, no devolverá nada.

4. Si se obtienen valores debido a la existencia de datos, se de-

vuelve como diccionario de Json y se muestran los resultados

al usuario.

Salida Correcta 1. (Caso en el que exista raíz léxica) Resultados que contengan

la raíz léxica de las palabras introducidas como parámetro de

búsqueda indiferentemente de la posición en la que se hayan

introducido.

2. (Caso en el que no exista) Se envía un mensaje indicando que

no existen resultados.


Estado Sistema Post-Uso 1. (Caso en el que exista raíz léxica) Barra de búsqueda vacía y

mostrando los resultados.

2. (Caso en el que no exista) Barra de búsqueda vacía y un

mensaje indicando que no hay resultados.

Cuadro 7: Caso 6 (Equivocación a la hora de escribir búsqueda)

21

3.4. Diseño de Bajo Nivel3.4.1. Esquema de la Base de Datos Pre-Modificación

Figura 10: Modelo Entidad Relación de la Base de Datos Inicial

22

En este primer esquema se pueden observar las tabla iniciales antes de porcesarlas

mediante el proceso de lematización de los datos que contienen. Las tablas y sus campos

dispuestos en el esquema son los siguientes:

Tabla 1: product

Esta tabla va a contener los datos pertenecientes a los productos de los que se dispone

información, y para ello se han dispuesto los siguientes campos:

id_product contiene el identificador del producto dentro de la tabla.

width contiene el valor del grosor del producto.

depth contiene el valor de la profundidad del producto.

height contiene el valor de la altura del producto.

weight contiene el valor del peso del producto.

last_update contiene la última modificación de los valores del producto.

ean13 contiene el código de barras en formato ean13 (European Ar-

ticle Number) del producto.

isbn contiene el el número del isbn (International Standard Book

Number) del producto.

reference contiene referencias pertenecientes al producto.

Cuadro 8: Tabla 1: product

Tabla 2: product_description

Esta tabla va a contener toda la descripción de la información referente a cada pro-

ducto, y para ello se han dispuesto los siguientes campos:

23


id_shop contiene el identificador de la tienda donde se encuentra el

producto.

id_lang contiene el identificador del lenguaje que se utiliza.

ean13 contiene el código de barras en formato ean13 (European Ar-

ticle Number) del producto.

isbn contiene el el número del isbn (International Standard Book

Number) del producto.

reference contiene referencias pertenecientes al producto.

name contiene el nombre del producto.

description contiene la descripción del producto en formato html.

meta contiene la acción que se puede llevar a cabo con el producto,

por ejemplo (“Comprar producto")

last_update contiene la última modificación de los valores del producto.

description_normal contiene la descripción del producto en formato de string.

Campo introducido al modificar el campo de description.

Cuadro 9: Tabla 2: product_description

Tabla 3: related_entity

Esta tabla va a contener todas las entidades que están relacionadas con cada producto,

y para ello se han dispuesto los siguientes campos:

24

id_entity contiene el identificador de la entidad dentro de la tabla.

id_type contiene el identificador del tipo del que se trata la entidad.


name contiene el nombre de la entidad.

description contiene la descripción de la entidad en formato html.

meta contiene la acción que se puede llevar a cabo con la entidad

que está referida al producto, por ejemplo (Çomprar produc-

to")

last_update contiene la última modificación de los valores de la entidad.

description_normal contiene la descripción de la entidad en formato de string.

Campo introducido al modificar el campo de description

Cuadro 10: Tabla 3: related_entity

Tabla 4: characteristic

Esta tabla va a contener todas las características pertenecientes a cada producto, y para

ello se han dispuesto los siguientes campos:

id_characteristic contiene el identificador de la característica dentro de la tabla.

id_type contiene el identificador del tipo del que se trata la caracterís-

tica.


name contiene el nombre de la característica.

Cuadro 11: Tabla 4: characteristic

Tabla 5: product_related_entity

Esta tabla va a contener todas las uniones existentes entre los productos y sus entida-

des relacionadas, y para ello se han dispuesto los siguientes campos:


id_type contiene el identificador del tipo del que se trata la entidad.

id_related_entity contiene el identificador de la entidad dentro de la tabla.

Cuadro 12: Tabla 5: product_related_entity

25

Tabla 6: product_characteristic

Esta tabla va a contener todas las uniones existentes entre los productos y sus caracte-

rísticas, y para ello se han dispuesto los siguientes campos:


id_type contiene el identificador del tipo del que se trata la caracterís-

tica.


Cuadro 13: Tabla 6: product_characteristic

26

3.4.2. Esquema de la Base de Datos Post-Modificación

Figura 11: Modelo Entidad Relación de la Base de Datos Inicial

27

En este segundo esquema se pueden observar que se han añadido 12 tablas más a las

que existía en un inicio, esto es debido al procesado de los datos mediante el proceso de

lematización. Las tablas y sus campos dispuestos en el esquema son los siguientes:

Tabla 1: product_description_index1

Esta tabla va a contener todas las lematizaciones/raíces léxicas de los datos perte-

necientes a los productos en forma de unigrama que se encuentren dentro de la tabla

product_description:

term contiene el término (en forma de unigrama) que se va a lema-

tizar en el campo de stem.

stem contiene la raíz del término (en forma de unigrama) que se ha

lematizado.


Cuadro 14: Tabla 1: product_description_index1


Esta tabla va a contener todas las lematizaciones/raíces léxicas de los datos pertene-

cientes a los productos en forma de digrama que se encuentren dentro de la tabla pro-duct_description:

term contiene el término (en forma de digrama) que se va a lemati-

zar en el campo de stem.

stem contiene la raíz del término (en forma de digrama) que se ha

lematizado.





cientes a los productos en forma de trigrama que se encuentren dentro de la tabla pro-duct_description:

28

term contiene el término (en forma de trigrama) que se va a lemati-


stem contiene la raíz del término (en forma de trigrama) que se ha

lematizado.





necientes a los productos en forma de tetragrama que se encuentren dentro de la tabla

product_description:

term contiene el término (en forma de tetragrama) que se va a le-

matizar en el campo de stem.

stem contiene la raíz del término (en forma de tetragrama) que se

ha lematizado.



Tabla 5: related_entity_index1


cientes a las entidades en forma de unigrama que se encuentren dentro de la tabla rela-ted_entity:




lematizado.


Cuadro 18: Tabla 5: related_entity_index1



cientes a las entidades en forma de digrama que se encuentren dentro de la tabla rela-

29

ted_entity:




lematizado.





cientes a las entidades en forma de trigrama que se encuentren dentro de la tabla rela-ted_entity:




lematizado.





necientes a las entidades en forma de tetragrama que se encuentren dentro de la tabla

related_entity:




ha lematizado.



30

Tabla 9: characteristic_index1


cientes a las características en forma de unigrama que se encuentren dentro de la tabla

characteristic:




lematizado.


Cuadro 22: Tabla 9: characteristic_index1



cientes a las características en forma de digrama que se encuentren dentro de la tabla

characteristic:




lematizado.





cientes a las características en forma de trigrama que se encuentren dentro de la tabla

characteristic:

31




lematizado.





cientes a las características en forma de tetragrama que se encuentren dentro de la tabla

characteristic:




ha lematizado.



3.4.3. Ejecución del servicio

En la imagen que tenemos a continuación ?? podemos observar que el cliente está

haciendo una búsqueda en el servicio web, pasando la solicitud al servidor, procesando

los datos en él, enviando una solicitud con los datos procesados a la base de datos de

MySQL, la base de datos devuelve los resultados sin encapsular y por último el servidor

envía los resultados de la solicitud encapsulados en un diccionario de Json mostrándolo

por pantalla al usuario que está utilizando el cliente.

32

Figura 12: Diagrama de Ejecución del Servicio

3.5. Arquitectura3.5.1. Diagrama de Flujo

El diagrama de flujo que se muestra a continuación 13, se trata de una explicación

gráfica de la arquitectura del servicio. A su vez, dicho diagrama se encuentra dividido en

3 situaciones diferentes.

En primer lugar está el cliente, que se va a encargar de realizar la solicitud de búsqueda

y de recibir la respuesta. En esta situación se puede observar como realiza una solicitud de

búsqueda (pudiendo utilizar el servicio de autocompletado implementado en el servicio),

la cual es encapsulada en un JSON que va a ser enviado al servidor para que lo procese.

Una vez el servidor termina de procesar la búsqueda, el cliente recibe un diccionario de

datos encapsulados en JSON, y los dispone para que el usuario que está utilizando el ser-

vicio los pueda observar.

En segundo lugar está el servidor, que se va a encargar de realizar todos los procesos

para poder obtener el resultado. En el apartado del servidor, se puede observar como

obtiene los datos de la búsqueda encapsulados en un JSON. Una vez obtiene los datos del

JSON, por un lado se dipone a lematizar la búsqueda por n-gramas, entre un rango de 1

a 4 (ambos incluidos). Por otro lado, se realiza el modelo de vectorización de TF-IDF, de

donde va a obtener los identificadores de los productos que poseen un mayor rango de

acierto con los datos introducidos como búsqueda.

Una vez, se obtiene la busqueda lematizada en n-gramas y los identificadores del mo-

delo vectorial, se realiza la búsqueda en la base de datos, de donde se van a recibir los

resultados de mayor similitud a la solicitud del usuario, y posteriormente se van a encap-

sular cada una de las respuestas en un JSON estándo todos estos a su vez dentro de un

diccionario. Cuando se obtiene dicho diccionario de JSON se procede a devolverselo al

cliente como la respuesta.

33

En tercer y último lugar, está la base de datos, donde se encuentran todos los datos

pertenecientes a los productos. Aquí es donde se va a realizar la búsqueda de los datos

solicitados por el cliente a través del servidor y una vez son obtenidos los resultados, estos

son enviados al servidor con el fin de que los encapsule y se los envíe al cliente.

34

Figura 13: Diagrama de Flujo

35

4. IMPLEMENTACIÓNEn este apartado se va a explicar los métodos y programas utilizados para poder rea-

lizar la implementación del servicio web de búsqueda. Para ello se ha dividido en varias

partes:

4.1. Fase de modificación del campo “description”En esta fase, se realizó una columna que contuviese los datos pertenecientes a los

campos de description de cada producto, obteniéndolos en formato string a partir de html.

Para llevarlo a cabo, se ha creado un programa capaz de adquirir de un texto en html, los

datos que este contenía en formato de string.

Las bibliotecas usadas para poder solventar el problema propuesto, son las pertene-

cientes a BeautifulSoup4 (para poder realizar el parseo de HTML a String) y PyMySQL

(para poder acceder a los datos pertenecientes a los productos dentro de la base de datos).

En primer lugar, mediante la biblioteca de BeautifulSoup4, se utilizó la siguiente línea

de código que realizaba el parseo:

soup = B e a u t i f u l S o u p ( e lemento , f e a t u r e s =" h tml . p a r s e r " )

En la línea de código podemos observar que el “elemento”, se trata de cada dato que

se ha obtenido de la base de datos, y una vez éste se parsea, se guarda en la variable

“soup”. Una vez se ha obtenido el dato en la variable “soup”, esta se procede a almace-

nar mediante una sentencia en SQL (utilizando la librería PyMySQL) en la columna de

“description_normal” existente en la tabla de la base de datos.

4.2. Fase de lematización de tablasEn esta segunda fase, se procedió a realizar la lematización de las tablas pertenecien-

tes a “product_description”, “related_entity” y “characteristics” con el fin de obtener las

raíces léxicas de los datos almacenados en estas tablas, disponiendolos en unigramas (in-

dex1), digramas (index2), trigramas (index3) y tetragramas (index4). Para llevar a cabo

este proceso, se han utilizado las bibliotecas pertenecientes a NLP, en especial a NLTK,

de donde se obtienen las funciones de SnowballStemmer (función que realiza la lema-

tización de un término), stopwords (para poder eliminar palabras como determinantes,

preposiciones, y signos innecesarios como pueden ser puntos y comas) y PyMySQL (pa-

ra poder manipular la base de datos).

36

En primer lugar, se sacan los datos de la base de datos con el fin de lematizarlos me-

diante las siguientes líneas de código:

stemmer = Stemmer ( ’ s p a n i s h ’ )

lexema = stemmer . s tem ( e l e m e n t o )

En la primera línea de código se realiza la inicialización del lematizador utilizando

el lenguaje del “español”, y posteriormente, en la segunda línea de código descrita, se

realiza la lematización del “elemento”, guardando la raíz léxica de dicho término en la

variable “lexema”.

Para poder realizar los n-gramas correspoondientes se usa el siguiente bucle for:

f o r i t em2 i n l i s t a L e x e m a s [ b : b+tam_ngrama ] :

i f l e n ( i t em2 . s t r i p ( ) ) != 0 :

c o n c a t 2 . append ( i t em2 )

b += 1

En este bucle, se sacan todos los lexemas obtenidos anteriormente y almacenados

dentro de la lista “listaLexemas”, y se recorren y almacenan en una lista denominada

“concat2”, según el tamaño de n-grama que se ha dispuesto en la variable “tam_ngrama”

Posteriormente, se utiliza una sentencia en SQL para crear y almacenar en la base de

datos las raíces léxicas obtenidas a partir de los términos correspondiendo cada una a un

n-grama diferente y almacenandose en la tabla de n-grama a la que pertenezca.

4.3. Fase de incorporación de índice “Full-Text” Index a las tablaslematizadas

En esta fase, se van a incluir unos índices a las columnas denominadas como “stem”,

con el fin de que a la hora de la búsqueda no dependa el orden de introducción de las

palabras, es decir, si se busca “guitarra funda” debe de dar los mismo resultados que “fun-

da guitarra”. Dicho índice que se va a introducir se denomina como “Full-Text Index”,

el cuál mediante una sentencia en SQL utilizada sobre la base de datos de tipo “ALTER

TABLE” se consigue modificar el campo para que lo admita. Un ejemplo de la sentencia

SQL puede ser la siguiente:

37

ALTER TABLE c h a r a c t e r i s t i c _ i n d e x 1 ADD FULLTEXT ( stem ) ;

4.4. Fase de creación de servicio webEn esta fase se va a proceder a inicializar el servicio web mendiante las bibliotecas

que proporciona Django.

Para poder crear el servicio, se procede a realizar las siguientes consultas en la termi-

nal del ordenador:

$django−admin s t a r t p r o j e c t S e a r ch

$python manage . py s t a r t a p p s e a r c h

De esta forma, conseguimos crear el servicio con la primera consulta, y mediante la

segunda creamos la carpeta que va a contener la aplicación, con el fichero “views.py”

que va a ser el que se va a modificar para poder realizar las funciones que va a utilizar el

buscador a definir.

4.5. Fase de creación de diccionarios de las tablas de unigrama parael uso del modelo vectorial

Con el fin de realizar el modelo vectorial sobre los datos de la búsqueda introdu-

cidos como input, se debe realizar previamente la creación de los diccionarios de las

tablas pertenecientes a los términos lematizados en unigramas de las tablas de “pro-

duct_description”,“related_entity” y “characteristics”. Para poder realizar dichos diccio-

narios se va a utilizar función corpora pertenecientes a la biblioteca de gensim, realizando

la siguiente línea de código para cada tabla:

d i c t i o n a r y = c o r p o r a . D i c t i o n a r y ( pdocs )

d i c t i o n a r y . s a ve ( ’ / Use r s / S a l v a / Desktop / Search_VL / s e a r c h / d i c t i o n a r i e s

/ vsm . d i c t ’ )

38

En dicha línea de código, la variable “pdocs” contiene los datos pertenecientes a las

tablas de unigramas, que mediante la función “corpora.Dictionary” crea un diccionario de

dicha tabla y lo guarda en la variable de “dictionary”. Una vez se obtiene el diccionario se

guarda en un fichero con extensión “.dict”, con el fin de poder utilizarlo posteriormente

en el modelo vectorial.

Posteriormente, se deben de crear los ficheros que contengan los vectores relativos a

cada elemento dentro de la base de datos y del diccionario creado. Para ello, se utiliza

las funciones doc2bow sobre el diccionario para crear los vectores y MmCorpus.serialice

perteneciente a la biblioteca de corpora con el fin de almacenar los vectores en un fichero

con extensión “.mm”. Este proceso se realiza mediante las siguientes líneas de código:

v e c t o r s = [ d i c t i o n a r y . doc2bow ( doc ) f o r doc i n docs ]

c o r p o r a . MmCorpus . s e r i a l i z e ( ’ / Use r s / S a l v a / Desktop / Search_VL / s e a r c h /

d i c t i o n a r i e s / vsm_docs .mm’ , v e c t o r s )

4.6. Fase de implementación de funciones y modelo vectorial TF-IDFen el servicio web

Una vez se ha creado el servicio, se va a proceder a realizar las funciones necesarias

para el funcionamiento del buscador en el fichero “views.py”.

Lo primero que hay que tener en cuenta, es que el servidor va a recibir un json como

input de entrada con los datos pertenecientes a la búsqueda y posteriormente va a tener

que devolver un diccionario de json conteniendo los datos de los resultados a dicha soli-

citud. Para poder recibir el json y a su vez devolver dicho diccionario, se debe de realizar

un método POST, adquiriendo los datos de entrada con la siguiente línea de código:

i f r e q u e s t . method == "POST" :

r e s p o n s e = j s o n . l o a d s ( r e q u e s t . body )

Y en segundo lugar, devolver los diccionarios de json con la siguiente lía de código:

39

r e t u r n J sonResponse ( d i c t i o n a r y , s a f e = F a l s e )

En segundo lugar, una vez se ha conseguido obtener el input como string, se procede

a realizar el proceso de vectorización, en el que se van a obtener los identificadores de

los productos que tienen mayor similitud con la búsqueda realizada. Para ello, primero se

cargan los diccionarios de cada tabla con las siguientes líneas de código:

d i c t i o n a r y P r o d u c t s = c o r p o r a . D i c t i o n a r y . l o a d (

’ s e a r c h / d i c t i o n a r i e s / v s m _ p r o d u c t _ d e s c r i p t i o n . d i c t ’ )

d i c t i o n a r y R e l a t e d E n t i t y = c o r p o r a . D i c t i o n a r y . l o a d (

’ s e a r c h / d i c t i o n a r i e s / v s m _ r e l a t e d _ e n t i t y . d i c t ’ )

d i c t i o n a r y C h a r a c t e r i s t i c s = c o r p o r a . D i c t i o n a r y . l o a d (

’ s e a r c h / d i c t i o n a r i e s / v s m _ c h a r a c t e r i s t i c . d i c t ’ )

En tercer lugar, una vez se han obtenido los diccionarios, se guardan en variables los

vectores previamente almacenados pertenecientes a cada elemento de cada tabla. Para ello

se realizan las siguiente líneas de código:

l o a d e d _ c o r p u s _ P r o d u c t s = c o r p o r a . MmCorpus (

’ s e a r c h / d i c t i o n a r i e s / v s m _ p r o d u c t _ d e s c r i p t i o n _ d o c s .mm’ )

l o a d e d _ c o r p u s _ R e l a t e d E n t i t y = c o r p o r a . MmCorpus (

’ s e a r c h / d i c t i o n a r i e s / v s m _ r e l a t e d _ e n t i t y _ d o c s .mm’ )

l o a d e d _ c o r p u s _ C h a r a c t e r i s t i c s = c o r p o r a . MmCorpus (

’ s e a r c h / d i c t i o n a r i e s / v s m _ c h a r a c t e r i s t i c _ d o c s .mm’ )

Posteriormente, una vez obtenidos los datos de los vectores, se procede a realizar los

modelos de TF-IDF y posteriormente se realizan las matrices de similitud entre los datos

obtenidos de los modelos TF-IDF. Todo este proceso se realiza mediante las siguientes

líneas de código:

t f i d f P r o d u c t s = models . T f id fMode l ( l o a d e d _ c o r p u s _ P r o d u c t s )

t f i d f R e l a t e d E n t i t y = models . T f id fMode l ( l o a d e d _ c o r p u s _ R e l a t e d E n t i t y )

t f i d f C h a r a c t e r i s t i c s = models . T f id fMode l (

l o a d e d _ c o r p u s _ C h a r a c t e r i s t i c s )

40

c o r p u s P r o d u c t s D = t f i d f P r o d u c t s [ l o a d e d _ c o r p u s _ P r o d u c t s ]

c o r p u s R e l a t e d E n t i t y D = t f i d f R e l a t e d E n t i t y [

l o a d e d _ c o r p u s _ R e l a t e d E n t i t y ]

c o r p u s C h a r a c t e r i s t i c s D = t f i d f C h a r a c t e r i s t i c s [

l o a d e d _ c o r p u s _ C h a r a c t e r i s t i c s ]

i n d e x P r o d u c t s = s i m i l a r i t i e s . M a t r i x S i m i l a r i t y ( co rpusP roduc t sD ,

n u m _ f e a t u r e s = l e n ( d i c t i o n a r y P r o d u c t s ) )

i n d e x R e l a t e d E n t i t y = s i m i l a r i t i e s . M a t r i x S i m i l a r i t y (

c o r p u s R e l a t e d E n t i t y D , n u m _ f e a t u r e s = l e n ( d i c t i o n a r y P r o d u c t s ) )

i n d e x C h a r a c t e r i s t i c s = s i m i l a r i t i e s . M a t r i x S i m i l a r i t y (

c o r p u s C h a r a c t e r i s t i c s D , n u m _ f e a t u r e s = l e n ( d i c t i o n a r y P r o d u c t s ) )

Una vez obtenidos las matrices de similitud, se preprocesa la búsqueda mediante el

proceso de lematización y se crean a su vez vectores de la misma búsqueda, observando

posteriormente mediante las matrices de similitud, el porcentaje de acierto que tiene con

cada entrada de la base de datos. El proceso descrito se realiza con las siguientes líneas de

código, donde las variables “qtidf_” pertenecen a los datos de la búsqueda una vez usados

sobre los modelos TF-IDF:

s i m P r o d u c t s = i n d e x P r o d u c t s [ q t f i d f P r o d u c t s ]

s i m R e l a t e d E n t i t y = i n d e x R e l a t e d E n t i t y [ q t f i d f R e l a t e d E n t i t y ]

s i m C h a r a c t e r i s t i c s = i n d e x C h a r a c t e r i s t i c s [ q t f i d f C h a r a c t e r i s t i c s ]

r a n k i n g P r o d u c t s = l i s t ( s o r t e d ( enumera t e ( s i m P r o d u c t s ) , key=

i t e m g e t t e r ( 1 ) , r e v e r s e =True ) )

r a n k i n g R e l a t e d E n t i t y = l i s t ( s o r t e d ( enumera t e ( s i m R e l a t e d E n t i t y ) , key

= i t e m g e t t e r ( 1 ) , r e v e r s e =True ) )

r a n k i n g C h a r a c t e r i s t i c s = l i s t ( s o r t e d ( enumera t e ( s i m C h a r a c t e r i s t i c s ) ,

key= i t e m g e t t e r ( 1 ) , r e v e r s e =True ) )

En este momento, obtenidos los rankings pertenecientes al porcentaje de acierto entre

las entradas y la búsqueda, se almacenan todos los identificadores de dichas entradas en

el orden de mayor a menor porcentaje, siendo estos dispuestos entre un 100 % y un 30 %

de acierto, en una lista para posteriormente ser usados en el proceso de matching dentro

de la base de datos.

Lleado a este punto, se procede a realizar el proceso de lematización por n-gramas

dispuesto en la “Fase de lematización de tablas” y posteriormente se realiza una llama-

da a la base de datos con la biblioteca de PyMySQL, en la que la sentencia está limitada

41

por los identificadores pertenecientes a los productos con mayor acierto sobre la búsqueda

obtenidos en el modelo de vectores TF-IDF, y los datos que se buscan son los lexemas dis-

puestos en n-gramas de la solicitud de búsqueda. Para realizar este proceso de matching

se ha realizado la siguiente línea de código, donde el primer “ %s” pertenece al índice

de tamaño de n-grama, el segundo al elemento perteneciente a la solicitud de búsqueda

lematizado en el tamaño que corresponda con el n-grama de la tabla donde se va a buscar,

y por último el tercero corresponde con la lista de identificadores que se va a usar para

limitar la búsqueda en las tablas de la base de datos:

queryMatchXGrama = " " " SELECT i d _ p r o d u c t FROM

p r o d u c t _ d e s c r i p t i o n _ i n d e x %s WHERE MATCH( stem ) AGAINST (’ % s ’ ) AND

i d _ p r o d u c t i n ( %s ) " " " %(i n d i c e , e lemento , l i s t a V e c t o r i z a c i o n )

Una vez obtenidos los resultados de la búsqueda, se procede a realizar el encapsula-

miento de los datos en un diccionario de json. Si la búsqueda es nula, es decir, no existen

resultados, se encapsulará en un json un mensaje que indique que no existen resultados ni

identificadores que correspondan con la búsqueda. Todo este proceso se realiza mediante

las siguientes líneas de código:

i f l i s t a F i n a l == O r d e r e d S e t ( ) :

r e s p u e s t a = {

" i d " : "No ID " ,

" name " : "No R e s u l t s "

}

l i s t a R e s p u e s t a . append ( r e s p u e s t a )

e l s e :

f o r n i n l i s t a F i n a l :

r e s p u e s t a = {

" i d " : n [ 0 ] ,

" name " : n [ 1 ] ,

}

l i s t a R e s p u e s t a . append ( r e s p u e s t a )

o r i g i n a l D i c t i o n a r y = {}

o r i g i n a l D i c t i o n a r y = {

" p r o d u c t o s " : l i s t a R e s p u e s t a

}

r e t u r n o r i g i n a l D i c t i o n a r y

42

4.7. Fase de creación de cliente de pruebasEn esta fase se procede a realziar la creación de un cliente para poder realizar pruebas

sobre el servicio web creado. Para ello se ha realizado un fichero html que contiene lo

necesario para poder introducir un texto de búsqueda, lo envíe encapsulado en un json

al servidor, y una vez devueltos los resultados en un diccionario de json, este ser capaz

de poder mostrarlos por pantalla en formato de tabla, indicando los campos de “ID” y de

“NAME” pertenecientes al producto.

Con el fin de que el cliente de pruebas pueda realizar dichas tareas, se va a utilizar

JQuery para poder enviar métodos POST al servidor y mostrar los resultados de forma

correcta por pantalla. El código descrito para que se encapsulen los datos de la búsqueda

en un json y devuelva los resultados en forma de tabla es el siguiente:

f u n c t i o n r e t u r n S e n t e n c e ( ) {

v a r e l e m e n t o = document . ge tE lemen tById ( " S e a r c h " ) . v a l u e

/ / a l e r t ( e l e m e n t o )

$ . a j a x ( {

t y p e : ’POST ’ ,

u r l : ’ / s e a r c h ’ ,

d a t a : JSON . s t r i n g i f y ( {

s e n t e n c e : e l e m e n t o

} ) ,

s u c c e s s : ( da t a , t e x t S t a t u s , jqXHR ) => {

c o n s o l e . l o g ( da t a , t e x t S t a t u s , jqXHR )

$ ( ’ t a b l e > tbody > t r > t d ’ ) . p a r e n t ( ) . remove ( ) ;

numberP roduc t s ( d a t a ) ;

} ,

c o n t e n t T y p e : ’ a p p l i c a t i o n / j s o n ’ ,

da t aType : ’ j s o n ’

} )

}

f u n c t i o n numberProduc t s ( d a t a ) {

p r o d u c t o s = d a t a [ " p r o d u c t o s " ] ;

v a r i t e m s = [ ] ;

$ . each ( p r o d u c t o s , f u n c t i o n ( key , v a l ) {

i t e m s . push ( "< t r >" ) ;

i t e m s . push ( "< t d i d = ’ ’ "+key+" ’ ’ > "+ v a l . i d +" </ td >" ) ;

i t e m s . push ( "< t d i d = ’ ’ "+key+" ’ ’ > "+ v a l . name+" </ td >" ) ;

i t e m s . push ( " </ t r >" ) ;

} )

$ ( ’< tbody / > ’ ,{ h tml : i t e m s . j o i n ( " " ) } ) . appendTo ( " t a b l e " ) ;

getNumber ( ) ;

}

43

4.8. Fase de implementación del servicio de autocompletadoComo función adicional al buscador del cliente, se ha realizado un método de auto-

completado que funciona cada vez que se levanta una tecla en la búsqueda. Para ello, se ha

realizado un método que se encarga de enviar una solicitud en formato json al servidor con

los datos que se han introducido en la barra de búsqueda hasta que se levanta una tecla,

realizando una llamada a la base de datos, devolviendo los nombres de los productos que

son similares a la búsqueda que se está realizando. El código utilizado para enviar el json,

está realizado en JQuery y la búsqueda en la base de datos se realiza de igual forma que en

el método de búsqueda que usa el servicio en el momento de buscar los resultados una vez

se ha hecho la solicitud de búsqueda completa. El código escrito en JQuery es el siguiente:

f u n c t i o n au toComple t e ( ) {

v a r e l e m e n t o = document . ge tE lemen tById ( " S e a r c h " ) . v a l u e

$ . a j a x ( {

t y p e : ’POST ’ ,

u r l : ’ / a u t o c o m p l e t e ’ ,

d a t a : JSON . s t r i n g i f y ( {

f r a s e : e l e m e n t o

} ) ,

s u c c e s s : ( da t a , t e x t S t a t u s , jqXHR ) =>{

c o n s o l e . l o g ( da t a , t e x t S t a t u s , jqXHR )

p r o d u c t o s = d a t a [ " p r o d u c t o s " ]

v a r a r r = [ ]

$ . each ( p r o d u c t o s , f u n c t i o n ( key , v a l u e ) {

i f ( $ . i n A r r a y ( v a l u e . name , a r r ) === −1) {

a r r . push ( v a l u e . name )

}

} )

$ ( " # S e a r c h " ) . a u t o c o m p l e t e ( {

s o u r c e : a r r

} ) ;

} ,

c o n t e n t T y p e : ’ a p p l i c a t i o n / j s o n ’ ,

da t aType : ’ j s o n ’

} )

}

4.9. Fase de implementación del filtro por número de resultadosLa última función que se ha implementado en el cliente, es el filtro de búsqueda por

número de elementos, es decir, el usuario que utiliza la aplicación decide el número de

elementos que quiere que le aparezcan por pantalla. El código utilizado ha sido descrito

44

en JQuery mediante el uso de botones en la interfaz, siendo este el siguiente:

f u n c t i o n getNumber ( ) {

$ ( document ) . on ( " c l i c k " , ’ #bu5 ’ , f u n c t i o n ( ) {

$ ( " t a b l e > tbody > t r " ) . h i d e ( ) . s l i c e ( 0 , 6 ) . show ( ) ;

} )

$ ( document ) . on ( " c l i c k " , ’ # bu10 ’ , f u n c t i o n ( ) {

$ ( " t a b l e > tbody > t r " ) . h i d e ( ) . s l i c e ( 0 , 11) . show ( ) ;

} )



} )



} )



} )



} )

$ ( document ) . on ( " c l i c k " , ’ #buTOT ’ , f u n c t i o n ( ) {

$ ( " t a b l e > tbody > t r " ) . show ( ) ;

} )

}

El código HTML queda descrito al final de la siguiente forma:

< d i v c l a s s =" c o n t a i n e r theme−showcase " r o l e =" main ">

< d i v c l a s s =" jumbo t ron ">

<h1 a l i g n =" c e n t e r "> I n t r o d u c e your o b j e c t t o s e a r c h here < / h1>

<p c l a s s =" t e x t −c e n t e r ">

< i n p u t t y p e =" t e x t " name = " S e a r c h " i d = " S e a r c h " onkeyup="

au toComple t e ( ) ">

< i n p u t t y p e =" s u b m i t " v a l u e =" Send " s t y l e =" background−c o l o r

: # 4 CAF50 ; c o l o r : rgb ( 2 5 5 , 255 , 255) ; " o n c l i c k =" r e t u r n S e n t e n c e ( ) ">

< d i v c l a s s ="w3−c o n t a i n e r " a l i g n =" c e n t e r ">

<h6>Number o f p r o d u c t s : < / h6>

< b u t t o n c l a s s =" b u t t o n " i d =" bu5 " >5 </ b u t t o n >






< b u t t o n c l a s s =" b u t t o n " i d ="buTOT">Todos < / b u t t o n >

</ div >

45

</p>

< t a b l e c l a s s = " t a b l e t a b l e −b o r d e r e d t a b l e −s t r i p e d t a b l e −hover ">

< t h r e a d >

< t r a l i g n =" c e n t e r ">

< t h b g c o l o r =" #9 b f f b c ">ID </ th >

< t h b g c o l o r =" #9 b f f b c ">NAME</ th >

</ t r >

</ t h r e a d >

</ t a b l e >

</ div >

5. PRUEBAS Y RESULTADOS

5.1. Prueba 1: Una palabra.

Figura 14: Prueba 1

46

5.2. Prueba 2: Dos palabras.

Figura 15: Prueba 2

47

5.3. Prueba 3: Tres palabras.

Figura 16: Prueba 3

5.4. Prueba 4: Cuatro palabras o más.

Figura 17: Prueba 4

48

5.5. Prueba 5: Búsqueda errónea.

Figura 18: Prueba 5

5.6. Prueba 6: Búsqueda de un elemento mal escrito.

Figura 19: Prueba 6

49

5.7. Prueba 7: Búsqueda de un elemento que no se encuentra dentrode la base de datos.

Figura 20: Prueba 7

5.8. Prueba 8: Búsqueda de palabras con caracteres UTF-8.

Figura 21: Prueba 8

50

5.9. Prueba 9: Búsqueda de elemento limitando resultados en 5 ele-mentos.

Figura 22: Prueba 9

5.10. Prueba 10: Muestra de sistema de autocompletado.

Figura 23: Prueba 10

51

5.11. Prueba 11: Búsqueda de elementos en distinto orden.

Figura 24: Prueba 11.1


52

5.12. Prueba 12: Búsqueda con una palabra (Error con devoluciónde elemento)

Como se puede observar en la imagen, se ha solicitado la búsqueda de una “guitarra”,

y se han obtenido datos de soporte de guitarra, fundas de guitarras... y guitarras entre

estos, en lugar de aparecer las guitarras en primer lugar.


53


6. DISCUSIÓNEl servicio de búsqueda que se ha desarrollado mejora en muchos aspectos respecto a

buscadores como pueden ser “Magento”, “Prestashop” o “Opencart”, debido a que uiliza

un proceso de lematización de búsquedas y resultados en vez de realizar la búsqueda por

el nombre del producto completo.

A su vez, el servicio de búsqueda implementa un proceso de modelo vectorial, utiliza-

do para poder reducir el número de las búsquedas en la base de datos según el porcentaje

de acierto que tiene la solicitud de búsqueda con los productos que existen dentro de la

base de datos.

Por otro lado, debido al problema existente y demostrado en la prueba número 12 26,

no se puede decir que supera a buscadores como pueden ser “Sphinx”, “Solr” y “Elastic-

Search” en cuanto a la búsqueda correcta al completo de términos compuestos únicamente

por una sola palabra.

54

7. CONCLUSIONESEl trabajo que se ha llevado a cabo en este proyecto, ha sido la realización de un

servicio de búsqueda para una empresa correspondiente al comercio electrónico. Dicho

servicio de búsqueda utiliza técnicas de lematización y modelación de vectores con el fin

de obtener los resultados más exactos a las búsquedas que el usuario que utiliza el servicio

realiza.

En primer lugar se realiza la lematización de la búsqueda con el fin de realizar en

segundo lugar, el modelo de vectores TF-IDF y la búsqueda en la base de datos (junto

con los identificadores obtenidos en el modelo de vectores) de los productos que más se

adcuan a la solicitud del cliente, devolviéndolos en un diccionario de json con el fin de

poder mostrarlo por pantalla al usuario.

Como mejora futura a este buscador, se pueden tener en cuenta el método de retro-

alimentación mediante Machine Lerning, utilizado para hacer que el servicio reciba los

resultados y los devuelva al cliente ordenados según el orden de preferencia, con el fin de

poder solventar el problema existente con la prueba 12 26.

REFERENCIAS[1] T. Rubenczyk, N. Dershowitz, Y. Choueka, M. Flor, O. Hod y A. Roth, Search

engine method and apparatus, 2003. dirección: https://patents.google.com/patent/US20030217052A1/en.

[2] A. Broder, “A taxonomy of web search”, ACM SIGIR Forum, vol. 36, n.o 2, pág. 3,

2002, ISSN: 01635840. DOI: 10.1145/792550.792552.

[3] S. R. Lawrence y C. L. Giles, Meta search engine, 2006. dirección: https://patents.google.com/patent/US6999959B1/en.

[4] D. Sullivan, “How Search Engines Work”, 2002. dirección: http : / / www .uniroma2.it/didattica/prog_web/deposito/search_engine.pdf.

[5] W. Chun, Core Python Programming. Prentice Hall Professional, 2001, Google-

Books-ID: mh0bU6NXrBgC, ISBN: 978-0-13-026036-9.

[6] J. Melton, “SQL language summary”, ACM Computing Surveys, 141–143, 1996.

[7] R. Camps Paré, Bases de datos. UOC, 2005, ISBN: 978-84-9788-269-9.

[8] Dirección: https://pymysql.readthedocs.io/en/latest/index.html.

[9] M.-P. Perea y H. Ueda, Método general de lematización con una gramática míni-ma y un diccionario óptimo. Aplicación a un corpus escrito dialectal. dirección:

https://lecture.ecc.u-tokyo.ac.jp/~cueda/kenkyu/zyoho/lematizacion.pdf.

55

[10] N. Madnani, “Getting started on natural language processing with Python”, Cross-roads, vol. 13, n.o 4, 5–5, 2007, ISSN: 15284972. DOI: 10.1145/1315325.1315330.

[11] Dirección: https://www.nltk.org/api/nltk.stem.html.

[12] pág. 369,

[13] L. Richardson, “Beautiful Soup Documentation”, pág. 68,

[14] J. Plekhanova, “Evaluating web development frameworks:”, pág. 20,

[15] E. T. Bray, “The JavaScript Object Notation (JSON) Data Interchange Format”,

2017, ISSN: 2070-1721. dirección: http://www.rfc-editor.org/info/rfc8259.

[16] W. B. Frakes y R. Baeza-Yates, eds., Information Retrieval: Data Structures andAlgorithms. Upper Saddle River, NJ, USA: Prentice-Hall, Inc., 1992, ISBN: 0-13-

463837-9.

[17] R. Rehurek y P. Sojka, “Gensim—Statistical Semantics in Python”, pág. 1,

[18] M. A. Alvarez, “Este manual ha sido realizado por los siguientes colaboradores de

DesarrolloWeb.com:”, pág. 96,

[19] J. Ramos, E-Commerce 2.0. XinXii, 2017, Google-Books-ID: RZE2DgAAQBAJ,

ISBN: 978-3-96142-470-2.

[20] R. C. Miller y K. Bharat, “SPHINX: a framework for creating personal, site-specific

Web crawlers”, Computer Networks and ISDN Systems, Proceedings of the Seventh

International World Wide Web Conference, vol. 30, n.o 1, 119–130, 1998, ISSN:

0169-7552. DOI: 10.1016/S0169-7552(98)00064-6.

[21] Proceedings of the SIGIR 2012 Workshop on Open Source Information Retrieval.Department of Computer Science, University of Otago, 2012, ISBN: 978-0-473-

22025-9.

[22] K. N. Vavliakis, G. Katsikopoulos y A. L. Symeonidis, “E-commerce Personaliza-

tion with Elasticsearch”, Procedia Computer Science, pág. 6, 2018.

56

Este documento esta firmado porFirmante CN=tfgm.fi.upm.es, OU=CCFI, O=Facultad de Informatica - UPM,

C=ES

Fecha/Hora Mon Jun 03 10:51:36 CEST 2019

Emisor delCertificado

[email protected], CN=CA Facultad deInformatica, O=Facultad de Informatica - UPM, C=ES

Numero de Serie 630

Metodo urn:adobe.com:Adobe.PPKLite:adbe.pkcs7.sha1 (AdobeSignature)

Documents

TRABAJO FIN DE GRADO Servicio de búsqueda inteligente para …oa.upm.es/55745/1/TFG_SALVADOR_GONZALEZ_GERPE.pdf · A su vez, existen varios tipos de consultas[2], realizadas en los