implementación de un software web crud bajo una...

Implementación de un software web CRUD bajo una base de datos no

relacional.

Ing. Carlos Andrés Tafur Delgadillo.

Grupo 1.

Noviembre 2017.

Universidad Francisco José de Caldas.

Especialización en Ingeniería de Software.

Bogotá

Implementación de un software web CRUD bajo una base de datos no

relacional.

Ing. Carlos Andrés Tafur Delgadillo.

Noviembre 2017.

Director:

Edgar Jacinto Rincón Rojas

Revisor:

Jorge Mario Calvo Londoño

Universidad Francisco José de Caldas.

Especialización en Ingeniería de Software.

Bogotá.

ii Tabla de Contenidos

1. INTRODUCCIÓN .................................................................................................................. 1 1. Título de la investigación ....................................................................................................... 1 1.1 Introducción .......................................................................................................................... 1

2. CONTEXTUALIZACIÓN DE LA INVESTIGACIÓN ............................................................ 2 2.1 Planteamiento del problema .............................................................................................. 2

2.2 Formulación del problema ................................................................................................ 4 2.3 Sistematización del problema ........................................................................................... 4

3. Objetivos ................................................................................................................................. 4 3.1 Objetivo general ................................................................................................................ 4

3.2 Objetivos específicos ........................................................................................................ 5 4. Justificación ............................................................................................................................ 5

4.1 Justificación práctica ......................................................................................................... 5 5 Hipótesis de trabajo.................................................................................................................. 6

6 Marco de referencia ................................................................................................................. 6

6.1 Marco teórico ........................................................................................................................ 6 6.2 Bases de datos relacionales y no relacionales ................................................................... 6

6. 3 Marco Conceptual ................................................................................................................ 9 6.3.1 Tipos de bases de datos no relacionales ......................................................................... 9 6.3.2 Sistemas de bases de datos no relacionales.................................................................. 14

6.3.3 Las más populares ........................................................................................................ 14

6.3.3 Documentales ............................................................................................................... 14 6.3.4 Bases de datos para grafos ........................................................................................... 15 6.3.5 ¿Qué es MongoDB? ..................................................................................................... 15

6.3.6 Características de Mongodb ......................................................................................... 15 6.3.7 Métodos para implementación CRUD ......................................................................... 16

7. ASPECTOS METODOLÓGICOS ....................................................................................... 20 7.1 Tipo de estudio ................................................................................................................ 20 7.2 Método de investigación ................................................................................................. 20

7.3 Fuentes y técnicas para la recolección de la información ............................................... 21 7.4 Tratamiento de la información ........................................................................................ 21

8. ALCANCES, LIMITACIONES Y RESULTADOS ESPERADOS .................................... 21 8.1 Alcances .......................................................................................................................... 21

8.2 Limitaciones .................................................................................................................... 22 8.3 Resultados esperados ...................................................................................................... 22

2. DESARROLLO DE LA INVESTIGACIÓN ........................................................................... 23 2.1 Análisis y Diseño ................................................................................................................ 23

2.1.1 Requerimientos funcionales ......................................................................................... 23

2.1.2 Requerimientos no funcionales .................................................................................... 26 2.2 Fase de planeación .............................................................................................................. 28

2.2.1 Capa de negocio ........................................................................................................... 28 2.2.2 Capa de aplicación ....................................................................................................... 28 2.2.3 Capa de infraestructura ................................................................................................ 30 2.2.4 Capa de motivación...................................................................................................... 31

2.2.5 Conclusión del proceso de arquitectura empresarial ................................................... 31

iii 2.3 Fase de desarrollo ............................................................................................................ 32

2.3.1 Framework web ........................................................................................................... 32

2.3.2 Fuente de datos ............................................................................................................ 33 2.3.3 Importación de datos .................................................................................................... 37 2.3.4 Categorización de datos ............................................................................................... 38

2.4 Fase de ejecución ................................................................................................................ 39 2.4.1 Interfaz de inicio .......................................................................................................... 39

2.4.2 Interfaz web para generación de reporte ...................................................................... 40 2.4.3 Interfaz para generación de reporte a través de consola .............................................. 41 2.4.3 Interfaz de lista de reportes .......................................................................................... 44 2.4.4 Interfaz de detalle de reporte........................................................................................ 45

2.5 Pruebas de rendimiento ....................................................................................................... 48 2.5.1 Metodología ................................................................................................................. 48 2.5.2 Herramienta de medición ............................................................................................. 49 2.5.3. Resultados obtenidos .................................................................................................. 50

2.5.4 Conclusiones de pruebas .............................................................................................. 50

3. Cierre de la investigación...................................................................................................... 51 3.1 Resultados alcanzados .................................................................................................... 51

3.2 Conclusiones ................................................................................................................... 51 3.3 Trabajos de investigación futuros ................................................................................... 52

ANEXOS ...................................................................................................................................... 52

Formato seguimiento proyecto ................................................................................................. 52

Oficio de advertencia soft ......................................................................................................... 52 Formato de aprobación de proyecto .......................................................................................... 52 Artículo de proyecto de grado................................................................................................... 52

Bibliografía ................................................................................................................................... 53

iv Lista de figuras

Ilustración 1 .................................................................................................................................... 8 Ilustración 2 .................................................................................................................................... 9 Ilustración 3 .................................................................................................................................. 10 Ilustración 4 .................................................................................................................................. 11 Ilustración 5 .................................................................................................................................. 13

Ilustración 6 .................................................................................................................................. 14 Ilustración 7 .................................................................................................................................. 14 Ilustración 8 .................................................................................................................................. 15 Ilustración 9 .................................................................................................................................. 28

Ilustración 10 ................................................................................................................................ 29 Ilustración 11 ................................................................................................................................ 30 Ilustración 12 ................................................................................................................................ 31 Ilustración 13 ................................................................................................................................ 32

Ilustración 14 ................................................................................................................................ 32

Ilustración 15 ................................................................................................................................ 33 Ilustración 16 ................................................................................................................................ 33

Ilustración 17 ................................................................................................................................ 36 Ilustración 18 ................................................................................................................................ 38 Ilustración 19 ................................................................................................................................ 39

Ilustración 20 ................................................................................................................................ 40






Ilustración 33 ................................................................................................................................ 44 Ilustración 34 ................................................................................................................................ 44 Ilustración 35 ................................................................................................................................ 44 Ilustración 36 ................................................................................................................................ 45 Ilustración 37 ................................................................................................................................ 45

Ilustración 38 ................................................................................................................................ 45 Ilustración 39 ................................................................................................................................ 46 Ilustración 40 ................................................................................................................................ 46 Ilustración 41 ................................................................................................................................ 47 Ilustración 42 ................................................................................................................................ 49

1

1. INTRODUCCIÓN

1. Título de la investigación

“Implementación de un software CRUD bajo base de datos no relacional”

1.1 Introducción

A pesar de los tropiezos que conlleva realizar un proyecto de desarrollo de software,

bien sea por falta de tiempo, mala planeación, falta de recursos o lo que es común falta de

entrar al detalle de lo que se necesita. Los sistemas de información han sido una solución

a todos los problemas cotidianos de una empresa o una persona, cuando la información no

era tan crucial e importante como lo es ahora, el almacenamiento de los datos los cuales

han sido bajo organizados en gestores de base de datos relacionales los cuales cuentan con

una estructura que debe definirse antes del desarrollo del software bajo un modelo de datos

dado.

Esto ha sido así, desde los años 60, al día de hoy no sólo las cosas han cambiado,

sino que el volumen de información que se maneja es abrumador y eso requiere no sólo

más recursos físicos, sino que las aplicaciones respondan de forma oportuna cuando se

solicite información.

En esta investigación se describe el revolucionario concepto que se ha venido

gestando hace algunos años para guardar la información de una forma nueva y novedosa

llamado “bases de datos no relaciones”. Veremos su definición, características, sus tipos y

cómo podemos integrarla en un proyecto de desarrollo de software.

2

2. CONTEXTUALIZACIÓN DE LA INVESTIGACIÓN

2.1 Planteamiento del problema

Una base de datos relacional es aquella que cumple a cabalidad con el modelo

relacional, garantizando la unicidad, integridad y normalización de los registros. Estas

bases de datos usan un lenguaje llamado SQL, que permite la manipulación y control de la

información. Desde comienzos de la popularización de Internet a mediados de los 90,

muchas empresas y personas comenzaron no sólo acceder, sino a ofrecer servicios a través

de la red.

Esto ha llevado un crecimiento vertiginoso en el volumen de información, la cual

ha sido almacenada de una forma tradicional, guardando datos de forma centralizada, es

decir, en una base de datos única con posibilidades de crecimiento vertical. Esto último

significa que, aunque es escalable conlleva costos de mantenimiento, soporte y futuras

actualizaciones. Lo que ha venido ocurriendo es que la información dejó de estar en un

sólo origen a tener múltiples fuentes de datos y vienen desde muchas partes y en formas

diferentes (texto plano, motores de base de datos, software), lo cual el concepto de

centralización pasó a la descentralización.

La descentralización es sólo una parte del problema, la otra parte está relacionada

con el volumen de la información, hoy por hoy empresas como la WDCC (World Data

Centre for Climate) que cuenta con alrededor de 220 Terabytes de información (Software,

3

2016) y seguirá en aumento. Estos grandes bancos de datos son de alto valor si se utiliza y

gestiona de la mejor manera, brindándole a la compañía un apoyo en sus operaciones

diarias.

Es entonces, cuando comienza a aparecer el concepto de bases de datos

documentales o no relacionales. Este tipo de base de datos, no obedece a un modelo

relacional y no requieren estructuras de datos fijas y su crecimiento es horizontal. Las

grandes ventajas de este tipo de base de datos es que el lenguaje no tiene por qué ser SQL,

son sistemas distribuidos y escalables horizontalmente. Todo esto dando como resultado

principal, la eficiencia, agilidad y facilidad de obtener resultados a partir de millones de

datos almacenados que en una base de datos relacional tardarían mucho en retornar

información, debido a la generación de grandes sentencias SQL.

Cuando una empresa planea desarrollar un software que permita no sólo el

almacenamiento de información, sino que retorne resultados de forma oportuna en el

momento que se requiera. Siempre se piensa en la creación de un modelo relacional, que

supla estos requerimientos, abandonando por defecto la integración de una base de datos

documental.

Para una compañía un software que permita obtener información de forma más

rápida, bien sea generando informes para el apoyo a la toma de decisiones o en el

almacenamiento de la información de sus procesos, será un valor agregado que se verá

reflejado en sus procesos de negocios.

4

2.2 Formulación del problema

¿Cómo un software bajo base de datos no relacional puede convertirse en una herramienta

que brinde información útil a una compañía de forma rápida y eficiente, demostrando estar

en un nivel superior al software con base de datos relacional?

2.3 Sistematización del problema

Los problemas comienzan a suceder con el transcurso del tiempo, donde la

información que ha sido almacenada se requiere ahora para generar informes que apoyen

en la toma de decisiones Inteligencia de Negocios, por ejemplo. Entonces,

¿Por qué no desarrollar un software que cuente con un sistema de base de datos

documental, que permita la gestión eficiente de la información a mediano y largo plazo?

¿Es posible demostrar desde la práctica, la fiabilidad y agilidad en las funciones

principales CRUD?

¿Cómo diseñar un modelo para una base de datos no relacional?

¿Qué tipo de gestores de bases hay en el mercado y cúal será el mejor candidato

que podemos usar en un software?

3. Objetivos

3.1 Objetivo general

5

Implementar un software para demostrar la fiabilidad y rendimiento de las

funciones CRUD en una base de datos no relacional en grandes volúmenes de información

a partir de información pública

3.2 Objetivos específicos

Diseñar un modelo de datos a partir de la lógica del negocio que permitan visualizar

la estructura de una base de datos no relacional.

Integrar el modelo de datos usando MongoDB como gestor de base de datos

documental para el almacenamiento de datos del software.

Demostrar el rendimiento y la fiabilidad de la aplicación web, realizando pruebas a

las funciones CRUD de la base de datos para demostrar su rendimiento.

4. Justificación

4.1 Justificación práctica

Las bases de datos desde la década de los 60, viene determinado por el uso que

estos sistemas han hecho las principales compañías de internet como Amazon, Google,

Twitter y Facebook. Estas compañías tenían que enfrentarse a nuevos desafíos en el

tratamiento de los datos motivados por el enorme crecimiento de la Web donde se requería

dar respuesta a la necesidad de proporcionar información procesada a partir de grandes

volúmenes de datos. Estas compañías se dieron cuenta de que el rendimiento y sus

necesidades de tiempo real eran más importantes que la consistencia de los datos, aspecto

6

este último al que las bases de datos relacionales tradicionales dedicaban una gran cantidad

de tiempo de proceso.

5 Hipótesis de trabajo

El desarrollo de un software utilizando una base de datos no relacional, permitirá

demostrar las ventajas que tienen para el manejo de grandes volúmenes de información. Al

no existir una estructura definida para el almacenamiento de información, permitirá

almacenar, consultar información mucho más rápido y de forma eficiente.

6 Marco de referencia

6.1 Marco teórico

Se deben tener en cuenta algunos conceptos claves para comprender en que se fundamenta

esta investigación.

6.2 Bases de datos relacionales y no relacionales

Las bases de datos relacionales han sido la única solución para el almacenamiento de datos

en todos los proyectos de software. Sin embargo, no todo lo que brilla es oro y muchos de

estos proyectos con el pasar del tiempo la información que van almacenando no sólo se

torna externa sino compleja sobre todo en el momento de consultar y presentarla al usuario.

Cuando esto comienza suceder la disponibilidad es lo primero que comienza a verse

7

afectado, el retorno de la información se vuelve demorado y la experiencia del usuario

comienza a decaer por dicha razón.

En las bases de datos relacionales funcionan a partir de un conjunto de propiedades

definidas como ACID que por sus siglas en inglés traduce como “Atomicidad, consistencia,

aislamiento y durabilidad. Según (Amazon Web Services, 15), respecto al término anterior

Atomicidad sería en términos coloquiales sería como “la transacción funciona o no

funciona”, ya que si en una sentencia SQL hay algo erróneo bien sea mal escrito o una

columna mal escrita dicha sentencia no será ejecutada y por ende será un error a corregir.

Según (Sullivan, 2015) la consistencia indica que una vez ejecutada esta sentencia

los datos deben acoplarse al esquema o estructura de nuestra base de datos. El aislamiento,

significa que esta y otras sentencias deben ser ejecutadas por separado. La durabilidad es

la capacidad de recuperarse de un error del sistema.

Los modelos de datos para las bases de datos no relacionales se normalizan en

tablas, las cuales tienen filas, columnas, índices, relaciones y otros elementos. Las bases

de datos no relaciones no suelen contener un esquema. Se suele utilizar una clave para

recuperar valores, conjuntos de columnas o documentos JSON semiestructurados y estos a

su vez traen otros documentos que contienen atributos de elementos relacionados.

Según el libro (Pramod J. Sadalage, 2013) las relaciones proporciona cierta

elegancia y simplicidad, pero también introduce limitaciones. En particular, los valores de

una tupla relacional tienen que ser simples: no pueden contener ninguna estructura, como

un registro anidado o una lista.

8

Que pueden tener estructuras mucho más ricas que las relaciones. Como resultado, si desea

utilizar una estructura de datos de información más rica, tiene que traducirla a una

representación relacional para almacenarla en disco.

De ahí la incompatibilidad de impedancia-dos representaciones diferentes que requieren

traducción, ver ilustración 1

Ilustración 1

Una orden de compra puede generarse a partir de la relación entre diferentes tablas de la base de

datos. - Autoría propia

Tabla órdenes

Datos de la orden

Cliente

Orden de compra

Tabla Clientes

Tabla ítems ordenes

Llave

v v

9

6. 3 Marco Conceptual

6.3.1 Tipos de bases de datos no relacionales

Llave - valor

Este tipo es la razón de existencia de las bases de datos NOSQL. Ya que la llave es

el identificador único y puede ser alfanumérico. El valor es lo que se almacenará. Las bases

de datos de valores clave se basan en principios mínimos para almacenar y recuperar datos.

Ilustración 2

Autoría propia

Según (Pramod J. Sadalage, 2013), A diferencia de las bases de datos relacionales,

no hay tablas, por lo que no hay características asociadas con tablas, como columnas y

restricciones en columnas. No hay necesidad de unirse en bases de datos de valor clave,

por lo que no hay claves foráneas. Las bases de datos de valores clave no admiten un

lenguaje de consulta enriquecido, como SQL.

Documental

Colección 1

Llave valor valor

Llave valor valor

Llave valor valor

Colección 2

Llave valor valor

Llave valor valor

Llave valor valor

10

Este tipo de base de datos almacena texto semiestructurado, puede ser JSON o

XML que cuentan con un esquema libre.

Una colección en formato JSON contiene la siguiente estructura:

{nombrecliente: “Nombre1”, apellidocliente: “Apellido”, numerocedula”, “12345”}

Una colección de tipo documental tendría como ejemplo los siguientes datos:

Empleado 1 Empleado 2

{

nombre: “Nombre1”,

apellido: “Apellido2”,

historialaboral:

[{

cargo: “Practicante”,

fechaInicio:“1-Feb-2016”,

fechatermino:“30-Jun-2016”

}]

}

{

nombre: “Nombre2”,

apellido: “Apellido2”,

ciudadreside: “Bogotá”

telefono: “4102019302,

historialaboral:

[{

cargo: “Practicante”,

fechaInicio:“1-Jul-2016”,

fechatermino:“30-Dic-2016”

}{

cargo: “Ingeniero de Sistemas”,

StartDate:“1-Feb-2016”,

endDate:“30-Jun-2016”

}]}

Ilustración 3

Autoría propia

11

Como podemos observar el cliente dos, cuenta con más datos que el cliente uno.

Esto desde la base de datos no supone un problema, ya que los desarrolladores pueden

añadir tantos datos adicionales como sean necesarios. Sin embargo, si son responsables de

manejarlos y validar que entre cada cliente tengan información en común.

Columnares

Estas permiten múltiples atributos por llave y su característica principal es el

almacenamiento en columnas y no filas como es usual.

Ilustración 4

Autoría propia

Esto resulta bastante útil cuando queremos almacenar análisis y predicción de

datos, inteligencia de negocios puede ser una opción.

Diferencias entre columnares y bases de datos relacionales

Una cosa que hace falta en las bases de datos es la compatibilidad para unir tablas.

Las tablas en las bases de datos relacionales tienen una estructura, y el sistema de gestión

Fila 1

Fila 2

nombres apellidos ciudad

John Smith Alemania

John Smith Alemania

12

de base de datos relacional se puede aprovechar esto sin embargo, en noSQL las

columnares puede variar de una fila a otra

Orientado a grafos

Este tipo permite representar la información como nodos y aristas que modelan la

relación que tienen entre ellos. A diferencia de los demás tipos que usan columnas y filas,

este tipo define en términos formales vértices y aristas. En (Sullivan, 2015), Un nodo es

una representación de un objeto que tiene un identificador y un conjunto de atributos. Y

una arista es una conexión entre dos nodos que contienen atributos de esa relación.

Un ejemplo de lo anterior, sería una red social donde una persona puede tener una

amista con más personas. El cual se representaría en el siguiente grafo.

13

Ilustración 5

Autoría propia

En la figura anterior están las personas que son los nodos y sus aristas que pueden

estar en cualquier orden y estas indican entre que personas tienen una amistad.

Según (Pramod J. Sadalage, 2013), Las bases de datos gráficas permiten una consulta más

eficiente cuando las rutas a través de los nodos están involucradas. Muchas áreas de

aplicación se modelan eficientemente como gráficos y, en base de datos de gráficos puede

simplificar el desarrollo de aplicaciones y minimizar la cantidad de código que debe

realizarse.

Pedro

Juan

Camilo

Victoria

Sarah

14

6.3.2 Sistemas de bases de datos no relacionales

En la página principal NoSQL (Nosql Database, 2017), dicen que hay más de 225

tipos de bases de datos no relacionales. Las bases de datos no relacionales se pueden

clasificar de acuerdo a los tipos anteriores.

6.3.3 Las más populares

Base de datos Versión actual Licencia

MongoDB 3.4 MongoDB inc

Cassandra 3.1 Apache

CouchDB 2.0 Apache

Redis 3.2 Redislabs

Ilustración 6

Información actualizada hasta la fecha de esta investigación.

Tomado de (DBig Cloud, 2017)

6.3.3 Documentales

Base de datos

CouchDB

HBase

Accumulo

Hypertable

Ilustración 7

Tomado de (Kovacs, 2017)

15

6.3.4 Bases de datos para grafos

Base de datos

OrientDB

Neo4j

Ilustración 8

Tomado de (Kovacs, 2017)

6.3.5 ¿Qué es MongoDB?

Según (Chodorow, 2013), Es una base de datos orientada a documentos, no de tipo

relacional. La razón principal para alejarse del modelo relacional es hacer que la escala sea

más fácil, pero hay otras ventajas también. Una base de datos orientada a documentos

reemplaza el concepto de "fila" por el "documento". Al permitir que los documentos

incrustados y arrays, al ser orientado a documentos permiten representar relaciones

jerárquicas complejas con un único registro.

6.3.6 Características de Mongodb

En el libro de (Chodorow, 2013) nos presenta cinco características principales:

Un documento es la unidad básica de datos para MongoDB y es aproximadamente

equivalente a una fila en un sistema de gestión de base de datos relacional (pero mucho

más expresivo).

Una colección puede ser pensada como una tabla con un esquema dinámico

Una sola instancia de MongoDB puede alojar múltiples bases de datos que puede tener

sus propias colecciones.

16

Cada documento tiene una clave especial, "_id", que es única dentro de una colección.

MongoDB viene con una consola que es útil para la administración de instancias de

MongoDB y manipulación de datos.

6.3.7 Métodos para implementación CRUD

De acuerdo con la documentación de MongoDB (Inc, 2017), la siguiente

información permite implementar las acciones básicas tales como el CRUD.

Método insertOne()

Este método permite insertar un solo registro.

db.productos.insertOne( { item: "celular", valor: 850.000 } );

El resultado será:

{"acknowledged" : true, "insertedId" : ObjectId("56fc40f9d735c28df206d078")}

Método insertMany()

Este método permite insertar múltiples registros en una sóla sentencia

db.productos.insertMany( [

{ item: "celular 1", valor: 850.000 },

{ item: "celular 1", qty: 1.200.000 },

{ item: "celular 1" , qty: 3.000.000 }

] );

El resultado será:

{ "acknowledged" : true,

17

"insertedIds" : [

ObjectId("562a94d381cb9f1cd6eb0e1a"),

ObjectId("562a94d381cb9f1cd6eb0e1b"),

ObjectId("562a94d381cb9f1cd6eb0e1c")

]}

Para los métodos de inserción, podemos defnir nuestros propios identificadores.

Sólo debemos añadir “_Id”, por ejemplo:

db.products.insert( { _id: 10, item: "box", qty: 20 } )

El resultado será:

{ "_id" : 10, "item" : "box", "qty" : 20 }

Método find()

Este método nos permite seleccionar un elemento en una colección y devuelve un

cursor a dichos elementos. Si queremos seleccionar el elemento con identificador

2, debemos hacer lo siguiente:

db.productos.find( { _id: 2 } )

El resultado será:

db. productos.find({ _id: { $in: [ 2, ObjectId("507c35dd8fada716c89d0013") ] }

})

Método updateOne()

Permite modificar un o más elementos de una colección. Este método puede

modificar campos específicos de una colección existente o modificarlo

completamente.

18

db.clientes.update(

{ name: "Charlie" },

{

nombre: "McLister",

cedula: 12345,

edad: 32

},

{ upsert: true })

Método updateMany()

Este método nos permite actualizar múltiples elementos de la colección a partir del

filtro

db.clientes.updateMany(

{ id: { 4 } }, { $set: { "Categoria" : “Platinum”} } );

El resultado sería:

{ "acknowledged" : true, "matchedCount" : 1, "modifiedCount" : 1 }

Donde nos indica que la actualización afectó a un elemento.

Método replaceOne()

Reemplaza un elemento en la colección basada en el filtro. Vamos a reemplazar,

por ejemplo, un nombre mal escrito.

db.restaurant.replaceOne(

19

{ "name" : "Carro modlo 2017" },

{ "name" : "Carro Modelo 2017" }

);

El resultado será:

{ "acknowledged" : true, "matchedCount" : 1, "modifiedCount" : 1 }

Indicando que ha encontrado un elemento con ese criterio y ha sido modificado.

Método deleteOne()

Este método no permite borrar un elemento en particular:

db.productos.deleteOne( { "_id" : 2 } );

El resultado nos indica que el identificador fue borrado:

{ "acknowledged" : true, "deletedCount" : 1 }

Método deleteMany()

Este método nos permite borrar múltiples registros a partir de un criterio

db.ordenes.deleteMany( { "cliente" : "Hoteles Estelar." } );

El resultado nos indica cuantos registros fueron borrados:

{ "acknowledged" : true, "deletedCount" : 31 }

Para los métodos anteriores es importante tener en cuenta lo siguiente:

Manejo de errores

En dado caso que algo falle debemos encerrar nuestras sentencias en un “try –

catch”, el cual nos permite obtener información si nuestra base de datos tuvo algún

problema.

Por ejemplo:

20

try {

sentencia_nosql

}catch (e){

print (e);

}

Evitar la duplicidad

Para evitar que MongoDB inserte el mismo documento más de una vez, debemos

crear un índice único en el campo de nombre. Con un índice único, si varias

aplicaciones emiten la misma actualización con upsert: true, el método”update”,

insertará correctamente un nuevo elemento.

7. ASPECTOS METODOLÓGICOS

7.1 Tipo de estudio

El tipo de estudio planteado para esta investigación es interactivo; ya que se

propiciará el uso de bases de datos no relacionales en el desarrollo de software.

7.2 Método de investigación

Se realizará un método de análisis inductivo, donde se demuestra todas las

características de una base de datos relacional y cómo puede ser un gran aliado en un

desarrollo de software. Explicando desde el origen de bases de datos no relacionales,

seleccionar un gestor de base de datos y describiendo los métodos disponibles para crear

software con ellos.

21

7.3 Fuentes y técnicas para la recolección de la información

Actualmente la información sobre NoSQL es escasa, pero existen dos libros

principales; No SQL Distilled de Pramod J. Sadalage - Martin Fowler y NoSQL For Mere

Mortals de Dan Sullivan, los cuales son muy descriptivos en la teoría que permite

demostrar al lector de forma fácil todo lo relacionado con el tema.

7.4 Tratamiento de la información

Una vez la información obtenida sea consolidada, se procederá a organizarse para

estudiar su aplicación en esta investigación. La información puede otorgar una

profundización de términos posiblemente desconocidos y que hagan falta revisar o probar.

8. ALCANCES, LIMITACIONES Y RESULTADOS ESPERADOS

8.1 Alcances

El alcance del proyecto será el desarrollo de software orientado a la web, donde se

permita visualizar el proceso CRUD en una base de datos no relacional. Este alcancé tendrá

las siguientes características:

1. Software orientado a la web.

2. Implementación el gestor de base de datos Mongo DB en su versión más reciente hasta la

fecha de este documento.

3. Importación de datos públicos abiertos.

4. Visualización de información de una forma más simple y fácil de entender.

22

8.2 Limitaciones

Una limitación principal será el no contar con un tamaño de información

considerable, para demostrar el rendimiento de las bases de datos no relacionales a la hora

de retornar información.

8.3 Resultados esperados

Se espera que esta investigación demuestre la fiabilidad, rendimiento y potencial

del desarrollo de un software bajo bases de datos no relacionales.

23

2. DESARROLLO DE LA INVESTIGACIÓN

2.1 Análisis y Diseño

2.1.1 Requerimientos funcionales

Número RE_1 Versión 1.0 Tipo de requerimiento Funcional

Nombre Página de inicio/principal

ESPECIFICACIÓN DEL REQUERIMIENTO

Origen La primera página del software, debe contar con información

relacionada al software y un enlace a la lista de reportes.

Descripción La información a visualizar debe ser la siguiente:

Título de proyecto

Información de autor

Link a módulo de reportes.

Condiciones de aceptación Ninguna

Prioridad Alta

Información externa Ninguna.


Nombre Módulo de reportes – Importación de datos


Origen Permitir la importación de datos a partir de una fuente externa,

para poder registrar dicha información en el software.

Descripción Mediante un formulario web, se debe ingresar los siguientes

datos para importar información:

Nombre de reporte.

Número de datos

Fuente de datos

Condiciones de aceptación La fuente de datos debe ser JSON.

Prioridad Alta


24



Motivo de la Versión Creación del requerimiento


Origen del Requerimiento Optimizar la carga de datos para grandes volúmenes de

información.

Descripción En el formulario debe existir un campo que indique el

número máximo de datos por grupo o lote al momento de

realizar la importación de datos.

Condiciones de aceptación RE_2

Prioridad Alta






Origen del Requerimiento Información de ejecución y rendimiento. Todas las

importaciones deben contar con la siguiente información

para efectos de análisis y control:

Tiempo de ejecución

Tiempo transcurrido

Descripción El tiempo de ejecución permitirá indicar cuanto tiempo llevó

realizar la importación, clasificación y registro de datos

únicamente.

El tiempo transcurrido indica cuanto tiempo llevó realizar la

tarea de importación.


Prioridad Alta

25





Origen del Requerimiento Clasificación de la fuente de información

Descripción Al momento de importar los datos, debe detectar cuales

categorías o tipos de información se repiten para clasificar

los grupos mediante categorías.

Condiciones de aceptación RE_2, RE_3, RE_4

Prioridad Alta


Nombre Módulo de reportes – Visualización de datos



Origen del Requerimiento Visualización de información

Descripción Una vez importada la información, deberá poder ser

visualizada mediante tablas que permitan su rápida

interpretación.


Prioridad Alta

26


Nombre Módulo de reportes – Borrado



Origen del Requerimiento Permitir el borrado de reportes.

Descripción Los reportes pueden ser borrados por el usuario.


Prioridad Alta

2.1.2 Requerimientos no funcionales

Número RE_1 Versión 1.0 Tipo de requerimiento No Funcional

Nombre Adaptable en diferentes dispositivos.



Origen del Requerimiento Responsive

Descripción La aplicación debe visualizarse correctamente en

dispositivos móviles.


Prioridad Baja

27


Nombre Imagen de aplicativo



Origen del Requerimiento Logo de la aplicación.

Descripción La aplicación debe contar con el logo de la universidad.


Prioridad Baja


Nombre Botones de la interfaz



Origen del Requerimiento Botones intuitivos

Descripción La aplicación debe contar con botones llamativos que

permitan identificar de forma fácil su acción relacionada.


Prioridad Baja

28

2.2 Fase de planeación

2.2.1 Capa de negocio

Según (Slagter , Doest, Lacob, Lankhorst, & Leeuwen, 2004), este punto de vista

se usa para mostrar la estructura y la composición de alto nivel de uno o más procesos

comerciales.

Ilustración 9

Autoría propia

En la imagen anterior, se indica que el proceso en el cual se apoyará el software es

la importación de datos y generación de reportes. En la parte inferior se describen los

procesos que conlleva realizar esto.

2.2.2 Capa de aplicación

Este punto de vista es útil para diseñar o comprender la estructura principal de

aplicaciones o componentes y los datos asociados, p. para crear un primer paso de trabajo.

(Slagter , Doest, Lacob, Lankhorst, & Leeuwen, 2004).

29

Ilustración 10

Autoría propia

En este punto de vista, se puede observar las funciones y módulos planteados para

el desarrollo de software.

Función aplicación web:

o Habrá dos formas de importar información externa a la página web, las

cuales son las siguientes:

Formulario web

Este formulario resulta el idóneo para volúmenes de información

bajos.

Consola de importación.

Esta interfaz permite importar grandes volúmenes de información

sin producir fallos como falta de memoria en el servidor.

Función datos públicos abiertos

o Una aplicación externa, que cuenta con un servicio web para la consulta de

información.

o Al servicio se accede mediante autenticación de datos.

o Esta función retorna la información necesaria para el software.

30

Interfaz reporte

o El resultado del proceso, que permite visualizar de forma clara la

información importada.

2.2.3 Capa de infraestructura

Este punto de vista permite visualizar el hardware y software de los cuales depende

la capa de aplicación.

Ilustración 11

Autoría propia

En primer lugar, se debe contar con un servidor web, el cual permita la correcta

ejecución de la aplicación web y el motor de base de datos. Las características con las

cuales debe contar son:

31

Sistema operativo Linux o Windows.

Servidor Apache.

Motor de base de datos MongoDB en su versión más reciente.

Composer, para manejo de dependencias.

Firewall con configuración de seguridades mínimas que eviten posibles intrusiones al

sistema.

Más arriba, tendremos un navegador web el cual estará instalado en el dispositivo del

usuario. Para que de esta manera pueda interactuar con el software.

2.2.4 Capa de motivación

Esta capa se fundamenta en presentar una visión completa o parcial sobre cuál es

la motivación de los stakeholders frente a sus objetivos principales y principios.

Ilustración 12

Autoría propia

En el punto de vista motivacional, al usuario tiene como objetivo importar altos

volúmenes de información pública con el fin de evaluar el rendimiento y cómo se comporta

la base de datos no relacional MongoDB. Una vez logrado esto, espera poder visualizar

todo el detalle de la información cargada.

2.2.5 Conclusión del proceso de arquitectura empresarial

32

Una vez realizada la arquitectura empresarial, se pudo comprender mejor alguno

de los procesos claves de lo que debe ser la aplicación web. También se identificaron los

aspectos más relevantes de la aplicación, los cuales son:

1. Datos públicos:

a. La fuente de datos de externa, debe permitir mediante autenticación la

obtención de diferentes volúmenes de información.

2. Carga de información

a. Debe contar con un formato de datos aceptable, para que pueda ser

interpretada al momento de realizar la importación.

3. Visualización de información:

a. Una vez cumplido lo anterior, la información debe visualizarse de forma

clara al usuario.

2.3 Fase de desarrollo

2.3.1 Framework web

Symfony es un framework orientado a objetos, desarrollado en lenguaje PHP. Será

usado como base en la cual se sustentará este proyecto. Tiene una ventaja importante frente

a otros, ya que, aunque deberá instalarse cuenta con el componente necesario para trabajar

aplicaciones bajo bases de datos MongoDB.

La implementación de un proyecto Symfony, es sencilla y se describe a

continuación.

1. Descargar el instalador Symfony.

Ilustración 13

Autoría propia

2. Sobre nuestro directorio, ejecutamos el siguiente comando:

Ilustración 14

Autoría propia

33

3. Una vez haya culminado el proceso anterior, nos movemos a la carpeta con nombre

“miproyecto”

Ilustración 15

Autoría propia

4. A partir de este momento, ya podemos ejecutar el comando “bin console” el cual

son comandos para poder ejecutar más acciones del symfony y comenzar el

desarrollo de la aplicación.

Ilustración 16

Autoría propia

2.3.2 Fuente de datos

Teniendo como objetivo el encontrar altos volúmenes registros de información

además de ser confiable, se estableció que el lugar adecuado para cumplir lo anterior sería

a partir del uso de la plataforma Open Data la cual está enfocada en ofrecer datos públicos

de diferentes entidades y que están disponibles para cualquier usuario.

Como resultado de la búsqueda se encuentran las siguientes posibles opciones para

usar en la aplicación, las cuáles son:

1. 311 Services Requests – New York

Número de registros: 1.6.2 millones.

2. 311 Services Requests – Miami

Número de registros: 1.39 millones.

La opción seleccionada será la uno “311 Services Requests”, este grupo de datos

contiene todas las solicitudes de servicio a la línea 311 en Nueva York, desde el 2010 hasta

la fecha y cuya actualización e inserción de nuevos datos se realiza de forma diaria.

34

Este grupo de datos contiene la siguiente estructura e información disponible:

Column Name Description Type

Unique Key Unique identifier of a Service Request (SR) in the open

data set Plain Text

Created Date Date SR was created Date & Time

Closed Date Date SR was closed by responding agency Date & Time

Agency Acronym of responding City Government Agency Plain Text

Agency Name

This is the fist level of a hierarchy identifying the topic of

the incident or condition. Complaint Type may have a

corresponding Descriptor (below) or may stand alone.

Plain Text

Complaint Type Full Agency name of responding City Government Agency Plain Text

Descriptor

This is associated to the Complaint Type, and provides

further detail on the incident or condition. Descriptor values

are dependent on the Complaint Type, and are not always

required in SR.

Plain Text

Location Type Describes the type of location used in the address

information Plain Text

Incident Zip Incident location zip code, provided by geo validation. Plain Text

Incident Address House number of incident address provided by submitter. Plain Text

Street Name Street name of incident address provided by the submitter Plain Text

Cross Street 1 First Cross street based on the geo validated incident

location Plain Text

Cross Street 2 Second Cross Street based on the geo validated incident

location Plain Text

Intersection

Street 1

First intersecting street based on geo validated incident

location Plain Text

Intersection

Street 2

Second intersecting street based on geo validated incident

location Plain Text

Address Type Type of incident location information available. Plain Text

City City of the incident location provided by geovalidation. Plain Text

Landmark If the incident location is identified as a Landmark the

name of the landmark will display here Plain Text

Facility Type If available, this field describes the type of city facility

associated to the SR Plain Text

Status Status of SR submitted Plain Text

35


Due Date

Date when responding agency is expected to update the SR.

This is based on the Complaint Type and internal Service

Level Agreements (SLAs).

Date & Time

Resolution

Description

Describes the last action taken on the SR by the responding

agency. May describe next or future steps. Plain Text

Resolution

Action Updated

Date

Date when responding agency last updated the SR. Date & Time

Community

Board Provided by geovalidation. Plain Text

Borough Provided by the submitter and confirmed by geovalidation. Plain Text

X Coordinate

(State Plane) Geo validated, X coordinate of the incident location. Number

Y Coordinate

(State Plane) Geo validated, Y coordinate of the incident location. Number

Park Facility

Name

If the incident location is a Parks Dept facility, the Name of

the facility will appear here Plain Text

Park Borough The borough of incident if it is a Parks Dept facility Plain Text

School Name

If the incident location is a Dept of Education school, the

name of the school will appear in this field. If the incident

is a Parks Dept facility its name will appear here.

Plain Text

School Number

If the incident location is a Dept of Education school, the

Number of the school will appear in this field. This field is

also used for Parks Dept Facilities.

Plain Text

School Region If the incident location is a Dept of Education School, the

school region number will be appear in this field. Plain Text

School Code If the incident location is a Dept of Education School, the

school code number will be appear in this field. Plain Text

School Phone

Number

If the facility = Dept for the Aging or Parks Dept, the

phone number will appear here. (note - Dept of Education

facilities do not display phone number)

Plain Text

School Address

Address of facility of incident location, if the facility is

associated with Dept of Education, Dept for the Aging or

Parks Dept

Plain Text

School City

City of facilities incident location, if the facility is


Parks Dept

Plain Text

36


School State

State of facility incident location, if the facility is


Parks Dept

Plain Text

School Zip Zip of facility incident location, if the facility is associated

with Dept of Education, Dept for the Aging or Parks Dept Plain Text

School Not

Found Y' in this field indicates the facility was not found Plain Text

School or

Citywide

Complaint

If the incident is about a Dept of Education facility, this

field will indicate if the complaint is about a particualr

school or a citywide issue.

Plain Text

Vehicle Type If the incident is a taxi, this field describes the type of TLC

vehicle. Plain Text

Taxi Company

Borough

If the incident is identified as a taxi, this field will display

the borough of the taxi company. Plain Text

Taxi Pick Up

Location

If the incident is identified as a taxi, this field displays the

taxi pick up location Plain Text

Bridge Highway

Name

If the incident is identified as a Bridge/Highway, the name

will be displayed here. Plain Text

Bridge Highway

Direction

If the incident is identified as a Bridge/Highway, the

direction where the issue took place would be displayed

here.

Plain Text

Road Ramp If the incident location was Bridge/Highway this column

differentiates if the issue was on the Road or the Ramp. Plain Text

Bridge Highway

Segment

Additional information on the section of the

Bridge/Highway were the incident took place. Plain Text

Garage Lot

Name

Related to DOT Parking Meter SR, this field shows what

garage lot the meter is located in Plain Text

Ferry Direction Used when the incident location is within a Ferry, this field

indicates the direction of ferry Plain Text

Ferry Terminal

Name

Used when the incident location is Ferry, this field

indicates the ferry terminal where the incident took place. Plain Text

Latitude Geo based Lat of the incident location Number

Longitude Geo based Long of the incident location Number

Location Combination of the geo based lat & long of the incident

location Location

Ilustración 17

37

Tomado de (OpenData, 2017)

2.3.3 Importación de datos

Teniendo clara que información se va utilizar, Open Data permite el consumo de

información a través de un servicio API, la url para descargar la información es a través de

“https://data.cityofnewyork.us/resource/fhrw-4uyv.json”, esta url permite una serie usar

ciertos parámetros que permiten organizar u obtener la información de un modo similar a

sentencias SQL, algunas de ellas son:

2.3.3.1 Filtrado de información

El parámetro “$where”, nos permite seleccionar sólo ciertos tipos de datos.

Ejemplo

https://data.cityofnewyork.us/resource/fhrw-

4uyv.json?$where=complaint_type=%27Rodent%27

2.3.3.2 Paginación de datos

El parámetro “$limit”, nos permite establecer un número máximo de datos:

https://data.cityofnewyork.us/resource/fhrw-4uyv.json?$limit=1

El parámetro “$limit”, nos permite establecer un número máximo de datos:

https://data.cityofnewyork.us/resource/fhrw-4uyv.json?$limit=50&$offset=150

2.3.3.3 Organización de información

El parámetro $order, nos permite fijar un orden sea ascendente o descendente.

https://data.cityofnewyork.us/resource/fhrw-

4uyv.json?$limit=5&$order=complaint_type%20ASC

38

2.3.4 Categorización de datos

El aspecto más importante de este software es la detección de categorías comunes

y su agrupación para poder ser interpretada de mejor manera. Esta categoría funciona de

la siguiente manera:

Ilustración 18

Autoría propia

Consulta

•Envío de parámetros al API.

Descarga

•Obtención de datos.

Categorización

•Registro de categorías únicas.

•Si la categorías ya está registrada la omite.

Registro de información

•Asignación de categoría.

Registro de reporte

•Visualización de información organizada y clasificada.

39

2.4 Fase de ejecución

2.4.1 Interfaz de inicio

De acuerdo al requerimiento RE_1, se coloca toda la información relacionada al

proyecto de grado, autor, información de la carrera y de la universidad.

Ilustración 19

Autoría propia

40

2.4.2 Interfaz web para generación de reporte

Damos clic en el botón “Agregar nuevo”, allí aparecerá un formulario web con la

siguiente información:

Ilustración 20

Autoría propia

Nombre de reporte:

El nombre el cual podremos consultar el reporte desde la aplicación web.

Ilustración 21

Autoría propia

Datos a importar:

Número de información que deseamos registrar.

Ilustración 22

Autoría propia

41

Agrupación de datos:

Este parámetro nos permite segmentar la información a descargar, ya que

existen muchas probabilidades que al traer toda la información de una vez

el servidor se quede sin recursos de memoria.

Ilustración 23

Autoría propia

Url del archivo JSON:

Es la ruta donde se encuentra la fuente de información, es importante que

tenga forma JSON.

Ilustración 24

Autoría propia

2.4.3 Interfaz para generación de reporte a través de consola

A través del comando “bin/console cargadatosmongo”, se llama la función que

permite importar los datos en segundo plano.

Ilustración 25

Autoría propia

42

Luego de ejecutar el comando, la aplicación nos solicitará ingresar los siguientes

datos.

Url del archivo JSON:

Ilustración 26

Autoría propia

Datos a importar:

Ilustración 27

Autoría propia

Agrupación de datos:

Ilustración 28

Autoría propia

Nombre de reporte:

Ilustración 29

Autoría propia

Una vez hecho lo anterior, la aplicación comenzará a importar y registrar los datos.

43

Ilustración 30

Autoría propia

Cuando el proceso haya terminado, nos mostrará a modo ilustrativo un reporte de

carga, con información de procesamiento de los datos y tiempo de ejecución en

milisegundos.

Ilustración 31

Autoría propia

A partir de este momento ya podremos visualizar el reporte desde la interfaz web:

Ilustración 32

Autoría propia

44

2.4.3 Interfaz de lista de reportes

Esta interfaz, permite visualizar todos los reportes generados a través del

software.

Ilustración 33

Autoría propia

Cuenta con algunas opciones que permiten gestionar esta información, por ejemplo:

Borrado individual o masivo de reportes:

Ilustración 34

Autoría propia

Paginación de resultados:

Ilustración 35

Autoría propia

45

Agregar nuevo reporte:

Ilustración 36

Autoría propia

Filtrado de información

Ilustración 37

Autoría propia

2.4.4 Interfaz de detalle de reporte

Detalle de tipos de solicitudes más realizadas:

Ilustración 38

Autoría propia

46

Ubicación geográfica de de solicitudes realizadas

Ilustración 39

Autoría propia

Mapa de calor de áreas donde más se realizan solicitudes

Ilustración 40

Autoría propia

47

Organización de información mediante tablas

Ilustración 41

Autoría propia

48

2.5 Pruebas de rendimiento

2.5.1 Metodología

Se realizan diferentes pruebas de estrés al servidor invocando una función que

permitía realizar el registro de información desde OpenData hacia a un documento en

MongoDB.

Esta prueba de estrés se compone de lo siguiente:

Creación de API, la cual va registrar grupos de información definidos

previamente en el código.

Llamado de API individual, simulando aplicaciones externas enviando la

solicitud de registro.

Llamado de API simultáneo, simulando aplicaciones externas enviando

solicitudes de registro al mismo tiempo.

Se realizarán las siguientes pruebas, basados en los siguientes datos:

Datos: El número de datos que serán registrados en la base de datos

MongoDB.

Peticiones: Simula el número de dispositivos a los cuales se está invocando el

API.

Concurrencia: Simula conexiones de dispositivos enviando datos

simultáneamente.

Datos Peticiones Concurrencia Tiempo

5000 1 1

5000 5 2

5000 10 4

5000 30 10

5000 50 20

10000 1 1

10000 5 2

10000 10 4

10000 30 10

10000 50 20

30000 1 1

30000 5 2

30000 10 4

30000 30 10

30000 50 20

Ilustración 42

Autoría propia

49

2.5.2 Herramienta de medición

Para realizar la prueba de estrés se utilizó la “Apache JMeter”, el cual es un

componente puede ser descargado en la página apache.

Esta herramienta permite la creación de planes de pruebas añadiendo varias

posibilidades, alguna de ellas descritas a continuación que fueron necesarias para hacer

las pruebas:

Thread Group: Permite definir los usuarios y el ciclo de concurrencia.

HTTP Request Defaults: Parámetros básicos de la url donde está el API.

HTTP Request: Definición completa del método que vamos a invocar en el API.

Listeners, View Results in Table: Permite visualizar los resultados en una tabla

Ilustración 43

Autoría Propia

50

2.5.3. Resultados obtenidos

Ilustración 44

Autoría propia

2.5.4 Conclusiones de pruebas

Durante las pruebas de rendimiento vemos un incremento progresivo y sostenido

en el tiempo de atención de las peticiones el cual es aún mayor cuando existe un alto

nivel de concurrencia.

Se debe tener en cuenta el ambiente en el cual se ejecutaron las pruebas, ya que la

configuración con la cual se cuenta es de un equipo de uso cotidiano y no tiene las

características de un servidor web de alta concurrencia. De acuerdo con lo anterior, los

datos en un ambiente real pueden ser aún más bajos.

Datos Peticiones Concurrencia Tiempo

5000 1 1 29.136

5000 5 2 32.265

5000 10 4 34.075

5000 30 10 44.506

5000 50 20 51.816

10000 1 1 60.537

10000 5 2 59.699

10000 10 4 69.568

10000 30 10 123.63

10000 50 20 176.489

30000 1 1 178.085

30000 5 2 248.084

30000 10 4 267.658

30000 30 10 390.365

30000 50 20 433.353

51

3. Cierre de la investigación

3.1 Resultados alcanzados

Terminada la fase de ejecución y cumplir con los requerimientos funcionales y no

funcionales planteados en la fase de análisis y diseño, se listan los siguientes aspectos que

fueron resultados de llevar a cabo el desarrollo del software planteado:

1. El utilizar la información de datos públicos abiertos, permitió demostrar la

fiabilidad de una aplicación web al momento de procesar un alto volumen de

información.

2. Cuando son más de 300 mil datos el sistema en el cual se encuentra alojada la

aplicación puede comenzar a fallar por falta de memoria para procesar la

aplicación. Al encontrarse con esto, se añadió la posibilidad de importar datos a

través de consola y el resultado es la importación de más de 1 millón de datos.

3. Respecto al punto anterior, es importante contar con los recursos de máquina

suficientes que permitan el procesamiento de un mayor número de datos.

4. La importación de registros mediante la agrupación, permite a la aplicación

realizar consultas segmentadas para la obtención de datos optimizando un mejor

aprovechamiento de los recursos.

5. MongoDB como gestor de base de datos noSQL, es robusto y muy estable para

gestionar los CRUD de una aplicación web.

6. Una de las grandes ventajas de la base de datos, es que nos permite añadir

diferentes longitudes de información según se requiera en cada registro realizado.

3.2 Conclusiones

Los datos públicos abiertos son un recurso importante para utilizar en diferentes

ámbitos como la inteligencia de negocios o medición de comportamiento de personas o

solicitudes de servicio por ubicaciones, zonas y tipos más comunes.

Al organizar y catalogar la información en tablas y elementos gráficos permiten un

análisis más claro y detallado. Los datos que se presentan inicialmente como texto puro e

inicialmente sin sentido. Se puede llegar a toda esta información, para tomar decisiones o

generar estrategias sociales.

El objetivo general fue cumplido en su totalidad, al demostrarse que es posible

desarrollar un software web CRUD para el análisis y gestión de altos volúmenes de

información sin generar altos costos de infraestructura para su procesamiento y

almacenamiento.

52

3.3 Trabajos de investigación futuros

Esta investigación puede profundizarse un poco más, desde uno de los siguientes

aspectos: 1. Comparativa funcional entre bases de datos relacionales y no relacionales.

2. Niveles de rendimiento entre base de datos relacionales y no relacionales.

3. Permitir generar reportes de análisis de información desde una fuente de datos con

origen diferente al formato JSON inicial.

Cualquiera de los anteriores puntos, puede llevar a cabo un mejor entendimiento

del rendimiento y alcance de un motor de base de datos no relacional, frente a uno

relacional.

ANEXOS

Formato seguimiento proyecto

Oficio de advertencia Software

Formato de aprobación de proyecto

Artículo de proyecto de grado

53

Bibliografía

Amazon Web Services. (2017 de Abril de 15). Obtenido de

https://aws.amazon.com/es/nosql/

Chodorow, K. (2013). Mongo DB The Definitive Guide. New York: O'Reilly Media.

DBig Cloud. (15 de Abril de 2017). Obtenido de Daniel Romero Sanchez:

http://www.dbigcloud.com/bigdata/75-bases-de-datos-nosql.html

Inc, M. (15 de Abril de 2017). Obtenido de

https://docs.mongodb.com/manual/reference/database-references/

Kovacs, K. (14 de Abril de 2017). Obtenido de https://kkovacs.eu/cassandra-vs-

mongodb-vs-couchdb-vs-redis

Nosql Database. (14 de Abril de 2017). Obtenido de http://nosql-database.org/

OpenData, N. (30 de 09 de 2017). NYC OpenData. Obtenido de NYC OpenData:

https://nycopendata.socrata.com/Social-Services/311-Service-Requests-from-

2010-to-Present/erm2-nwe9

Pramod J. Sadalage, M. F. (2013). NoSQL Distilled. Indiana: Pearson Education, Inc.

Slagter , R., Doest, H., Lacob, M.-E., Lankhorst, M., & Leeuwen, D. (2004). Viewpoints

Functionality and Examples. Portugal.

Software, E. (17 de Enero de 2016). Evaluando Software. Obtenido de Evaluando

Software: http://www.evaluandosoftware.com/ranking-bases-datos-las-10-mas-

grandes/

Sullivan, D. (2015). No SQL For Mere Mortals. Michigan: Pearson Education, Inc.

implementación de un software web crud bajo una...

Documents