• No se han encontrado resultados

Implementación de un Software Web CRUD Bajo una Base de Datos no Relacional

N/A
N/A
Protected

Academic year: 2020

Share "Implementación de un Software Web CRUD Bajo una Base de Datos no Relacional"

Copied!
58
0
0

Texto completo

(1)

relacional.

Ing. Carlos Andrés Tafur Delgadillo.

Grupo 1.

Noviembre 2017.

Universidad Francisco José de Caldas.

Especialización en Ingeniería de Software.

(2)

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.

(3)

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

(4)

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

(5)
(6)

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

(7)

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

(8)

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á

(9)

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

(10)

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

(11)

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.

(12)

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

(13)

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

(14)

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

(15)

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

{

cargo: “Ingeniero de Sistemas”,

StartDate:“1-Feb-2016”,

endDate:“30-Jun-2016”

}]}

Ilustración 3

(16)

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

(17)

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

(18)

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

(19)

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

(20)

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

(21)

 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á:

(22)

"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

(23)

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.

(24)

{ "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.

(25)

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

(26)

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.

(27)

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

(28)

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.

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

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

ESPECIFICACIÓN DEL REQUERIMIENTO

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

(29)

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

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

Motivo de la Versión Creación del requerimiento

ESPECIFICACIÓ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

Información externa Ninguna.

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

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

Motivo de la Versión Creación del requerimiento

ESPECIFICACIÓN DEL REQUERIMIENTO

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.

Condiciones de aceptación RE_2

(30)

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

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

Motivo de la Versión Creación del requerimiento

ESPECIFICACIÓN DEL REQUERIMIENTO

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

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

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

Motivo de la Versión Creación del requerimiento

ESPECIFICACIÓN DEL REQUERIMIENTO

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.

Condiciones de aceptación RE_6

(31)

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

Nombre Módulo de reportes – Borrado

Motivo de la Versión Creación del requerimiento

ESPECIFICACIÓN DEL REQUERIMIENTO

Origen del Requerimiento Permitir el borrado de reportes.

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

Condiciones de aceptación Ninguna

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.

Motivo de la Versión Creación del requerimiento

ESPECIFICACIÓN DEL REQUERIMIENTO

Origen del Requerimiento Responsive

Descripción La aplicación debe visualizarse correctamente en dispositivos móviles.

Condiciones de aceptación Ninguna

(32)

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

Nombre Imagen de aplicativo

Motivo de la Versión Creación del requerimiento

ESPECIFICACIÓN DEL REQUERIMIENTO

Origen del Requerimiento Logo de la aplicación.

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

Condiciones de aceptación Ninguna

Prioridad Baja

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

Nombre Botones de la interfaz

Motivo de la Versión Creación del requerimiento

ESPECIFICACIÓN DEL REQUERIMIENTO

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.

Condiciones de aceptación Ninguna

(33)

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

(34)

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.

(35)

 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

(36)

 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.

(37)

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

(38)

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.

(39)

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

(40)

Column Name Description Type

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

associated with Dept of Education, Dept for the Aging or Parks Dept

(41)

Column Name Description Type

School State

State of facility incident location, if the facility is

associated with Dept of Education, Dept for the Aging or 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

(42)

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.

(43)

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

(44)

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

(45)

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

(46)

 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

(47)

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

(48)

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

(49)

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

(50)

 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

(51)

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

(52)

Organización de información mediante tablas

Ilustración 41

(53)

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

(54)

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

(55)

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

(56)

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.

(57)

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

(58)

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/

Referencias

Documento similar

Lo que relaciona a las aplicaciones web con la base de datos, es la capa de acceso a datos, por lo que para llevar a cabo las pruebas de eficiencia bajo carga intensiva a

Se caracterizan, además, la metodología de desarrollo de software, la herramienta de modelado, el lenguaje de programación Web, el sistema gestor de base de datos y el sistema

Para realizar un buen diseño de una BD hay que tener en cuenta varios aspectos importantes como: la integridad de los datos, la normalización del diseño, la

Si para construir y evaluar una FBF necesitamos una interpretación y un LPO, para todo esquema de base de datos relacional (BDR) y para cada estado de base de datos

De non ser así, as facturas non poderán tramitarse para o pago, e a USC, a través do responsable de asuntos económicos do centro da USC que solicitou os seus servicios Rexeitará

Minería de Datos Tipo de Software Plataforma Base de Datos Tipo de Reportes

Resumen – En este trabajo se ha desarrollado una base de datos relacional con el fin de integrar los resultados obtenidos mediante un método de análisis del reparto de cargas

Es lógico que así sea por el propio concepto y naturaleza de estos prin- cipios, pero también se percibe con cierta claridad que uno de los cuatro principios informadores, la Unidad