UNIVERSIDAD TECNOLOGICA DE PANAMÁ

FACULTAD DE INGENIERIA DE SISTEMAS COMPUTACIONALES

DEPARTMENTO DE COMPUTACIÓN Y SIMULACIÓN DE SISTEMAS

COMPARACIÓN DE UNA BASE DE DATOS RELACIONAL CONTRA UNA BASE

DE DATOS NO RELACIONAL EN UN AMBIENTE CLOUD

ASESOR

PROF. VICTOR LOPEZ CABRERA Msc.

INTEGRANTES

LUIS EDUARDO VIVAR 8-857-210

JUSTINO ORTIZ 8-822-430

Trabajo de Graduación para optar a los Títulos de Licenciado en Ingenieria en Sistemas y

Computación y Licenciado en Redes Informaticas

2016
 Agradecimientos

El grupo de trabajo de esta investigación le agradece primerametne a Dios Todopoderoso por

permitirnos vivir la experiencia de realizar este proyecto de investigación cientifica, darnos
las fuerzas para cumplir todos los retos que enfrentamos y suplir los recursos para concluirlo
con éxito.

Queremos agradecer a el Profesor Victor Lopez, por fungir como asesor y consejero, por su
constante motivación y guía incondicional para realizar este proyecto.

A la Universidad Tecnologica de Panamá (UTP) y su cuerpo docente, por darnos un entorno

en el cual pudimos desarrollarnos y crecer como profesionales, brindarnos los conocimientos
en el area de las TICs que sentaron las bases de nuestro entendimiento.

2
 Dedicatoria

Luis:
A Dios Todopoderoso que cada día me da cada día fortaleza para seguir adelante y a quien
le debo todo lo que tengo y soy.

A mi familia que me han apoyado y empujado incansablemente con amor, a conseguir todas
las metas que me he propuesto y por ser un pilar importante en mi desarrollo como persona
y profesional.

A mis profesores los cuales vieron potencial en mi y lo supieron explotar brindame su

confianza y enseñanzas.

A mis amigos que han estado conmigo aguantandome, motivandome y ayudadome a lo largo
de este arduo camino. Ustedes son una parte muy importante de mi vida, gracias ya que sin
ustedes no podria ser la persona que soy el dia de hoy.

“Ama y haz lo que quieras “

San Agustín

Justino:
Agradezco a Dios, a mi familia y a mis compañeros y sobretodo al profesor Víctor López
por su dedicación por nosotros en este proyecto.

3
 Indice

Agradecimientos ................................................................................................................................ 2
Dedicatoria ......................................................................................................................................... 3
Resumén Descriptivo ........................................................................................................................ 7
Introducción....................................................................................................................................... 8
Capitulo 1: - Fundamentos de la tecnología de Bases de Datos .................................................. 10
1.1. Almacenamiento de la información a lo largo del tiempo ................................................ 10
1.1.1. Siglo XIX y principios del siglo XX ............................................................................. 10
1.1.2. Década de 1950. ............................................................................................................ 10
1.1.3. Década de 1960. ............................................................................................................ 11
1.1.4. Década de 1970. ............................................................................................................ 13
1.1.5. Década de 1980. ............................................................................................................ 14
1.1.6. Década de 1990. ............................................................................................................ 14
1.1.7. Bases de datos en el siglo 21 ......................................................................................... 15
1.2. Definición .......................................................................................................................... 16
1.3. ACID ................................................................................................................................. 17
1.4. Clasificación de las bases de datos .................................................................................... 18
1.4.1. Según la variabilidad de la base de datos .................................................................. 18
1.4.2. Según el contenido .................................................................................................... 18
1.5. Modelo de bases de datos .................................................................................................. 20
1.5.1. Modelo jerarquico ..................................................................................................... 20
1.5.2. Modelo de red............................................................................................................ 21
1.5.3. Modelo de Fichero Invertido ..................................................................................... 22
1.5.4. Modelo Relacional .................................................................................................... 23
1.5.5. Modelos Post Relacionales........................................................................................ 33
1.6. Sistema Gestor de Bases de datos ..................................................................................... 36
Capitulo 2: - Computación en la nube ........................................................................................... 44
2.1. ¿Qué es la computación en la nube? ................................................................................. 44
2.2. La nube informatica en los ultimos años ........................................................................... 44
2.3. Caracteristicas principales ................................................................................................. 46
2.4. Servicios ofrecidos ............................................................................................................ 47
2.4.1. Software como servicio ............................................................................................. 47

4
 2.4.2. Plataforma como servicio .......................................................................................... 49
2.4.3. Infraestructura como servicio .................................................................................... 50
2.5. Clasificación de la Nube ................................................................................................... 51
2.6. Aspectos de seguridad ....................................................................................................... 52
Seguridad como servicio ........................................................................................................... 52
Seguridad del explorador .......................................................................................................... 52
Autenticación ............................................................................................................................ 53
Pérdida de gobernanza .............................................................................................................. 53
Lock-In ...................................................................................................................................... 53
Protección de los datos .............................................................................................................. 53
2.7. Limitaciones ...................................................................................................................... 54
Pérdidas de datos/fuga ............................................................................................................... 54
Dificultad de valorar la fiabilidad de los proveedores............................................................... 54
Fuerza de los mecanismos de autentificación ........................................................................... 54
2.8. Microsoft Azure ................................................................................................................ 54
2.8.1. Implementación ......................................................................................................... 55
2.8.2. Caracterisiticas de Azure ........................................................................................... 56
2.8.3. Componentes de la plataforma .................................................................................. 57
2.8.4. Beneficios de Windows Azure .................................................................................. 58
Capitulo 3: - Comparación de Bases de datos Relacionales contra Bases de datos No
Relacionales y sus gestores de bases de datos ............................................................................... 60
3.1. SQL Server ........................................................................................................................ 60
3.1.1. Caracteristicas ........................................................................................................... 60
3.1.2. Versiones ................................................................................................................... 61
3.1.3. Programación ............................................................................................................ 62
3.1.4. Interfaz de usuario ..................................................................................................... 63
3.1.5. Servicios .................................................................................................................... 64
3.1.6. Capacidades y herramientas basicas.......................................................................... 64
3.1.7. Funciones definidas por el usuario ............................................................................ 69
3.1.8. Consultas Distribuidas............................................................................................... 70
3.1.9. El optimizador ........................................................................................................... 70
3.2. MongoDB .......................................................................................................................... 71
3.2.1. Caracteristicas ........................................................................................................... 71

5
 3.2.2. Como funciona MongoDB ......................................................................................... 73
3.2.3. Casos de uso .............................................................................................................. 73
3.2.4. ¿Dónde no se debe usar MongoDB? ......................................................................... 74
3.3. Comparación entre bases de datos relacionales y bases de datos no relacionales ............. 75
3.3.1. ¿Cuándo utilizar SQL? .............................................................................................. 76
3.3.2. ¿Cuándo utilizar NoSQL? ......................................................................................... 77
Capitulo 4: Pruebas de desempeño de los ambientes ................................................................... 78
4.1. Motivación y metodología de las pruebas ......................................................................... 78
4.2. Caracteristicas de las de prueba......................................................................................... 78
4.3. Detalles de las pruebas de desempeño .............................................................................. 79
4.3.1. Medicion del tiempo.................................................................................................. 79
4.3.2. Medición de variables del servidor ........................................................................... 80
4.4. Configuración del ambiente virtual ................................................................................... 81
4.4.1. Base de datos a utilizar .............................................................................................. 81
4.5. Resultado de las pruebas ................................................................................................... 83
4.5.1. Pruebas de inserción .................................................................................................. 83
4.5.2. Pruebas de consulta y lectura .................................................................................... 86
4.6. Conclusiones de las pruebas de desempeño ...................................................................... 92
Conclusiones .................................................................................................................................... 93
Trabajos Futuros ............................................................................................................................. 94
Recomendaciones ............................................................................................................................ 95
Referencias Bibliograficas .............................................................................................................. 96

6
 Resumén Descriptivo

Las bases de datos y los enotrnos de nube son elementos que han marcado una tendencia
creciente en los ultimos años a nivel empresarial

Este trabajo muestra una comparación entre los entornos de bases de datos relacionales contra
bases de datos no relacionales en un entorno totalmente virtual en la nube.

Se realizaron pruebas tanto de lectura y consulta como de escritura en los ambientes virtuales
proporcionados por Windows Azure, con las cuales pudimos medir el tiempo que le toma a
las iteraciones completarse y ademas medir el consumo de recursos virtuales que estas
representaban.

7
 Introducción

En esta parte introducimos al lector a este proyecto de graduación explicando el contexto de

la investigación, luego se explica nuestras motivaciones y metas y una descripción de los
capitulos que comprenden este trabajo.

Contexto de la investigación

Este trabajo de investigación se llevo a cabo en la Facultad de Ingenieria de Sistemas

Computacionales de la Universidad Tecnologica de Panamá, bajo la guía del profesor Victor
Lopez el cual fungio como asesor de este trabajo.

La plataforma en la cual se desarrollo es la plataforma de nube informatica: Windows Azure

proporcionada con Microsoft en donde se crean dos maquinas virtuales aprovicionadas con
Windows Server 2012 R2 y Ubuntu Server 15.10 cada una con un gestor de base de datos,
los cuales son: SQL Server 2014 SPI y Mongo Community Server 3.2.6 respectivamente.

Motivaciones y metas

Las bases de datos son estructuras dedicadas y construidas para el almacenamiento de los
datos, de este modo con el avance de la tecnologia hemos pasado distintos paradigmas para
provicionamiento de bases de datos, de esto modo empezamos a ver cada vez mas empresas
y desarrolladores cambiando de su infraestructura en premisas a infraestructuras que se
acomoden a sus necesidades al tiempo que estas sean lo suficientemente flexibles para poder
escalar en necesidades, de esta forma vemos el nacimiento de las bases de datos en nube o
base de datos como servicio.

A pesar de los beneficios que estan aportan los usuarios no tienen conocimiento de esta nueva
forma de utilizar las bases de datos.

Este trabajo tiene como meta mostrar como se comportan estas bases de datos en entornos de
nubes informaticas y deja para trabajos posteriores las bases para poder realizar un sin
numero de trabajos basados de bases de datos tanto relacionales como no relacionales en
infraestructura Cloud.

8
Las siguientes interrogantes conforman nuestras preguntas de investigación:

 ¿Cómo se utilizan las bases de datos en entorno Cloud?

 ¿Es importante los recursos de los cuales se aprovicionan las maquinas virtuales?
 ¿Cómo podemos utilizar la metodologia de nube?
 ¿Qué podemos utilizar para tener una infraestructura de bases de datos relacional en
un ambiente Cloud?
 ¿Qué podemos utilizar para tener una infraestructura de bases de datos no relacional
en un ambiente Cloud?

Con este trabajo logramos responder estas interrogantes en base a la documentación teorica
y tambien hemos logrado comprobar mediante formulaciones experimentales el
comportamiento de la bases de datos utilizadas en un entorno de nube.

Descripción de los Capitulos

La estructuraa de este docuemento es la siguiente:

 Capitulo 1: una introducción a la tecnologia de bases de datos, su historia, modelos,

tipos de bases de datos y sistemas gestores de bases de datos.
 Capitulo 2: una explicación detallada de el modelo de computación en la nube,
caracteristicas principales, los servicios que ofrece, clasificaciones y el entorno de
Windows Azure.
 Capitulo 3: provee una comparación teorica de los modelos de bases de datos
relacionales contra los modelos de bases de datos no relacionales, haciendo enfasis
en los sistemas de SQL Server y MongoDB.
 Capitulo 4: presenta las pruebas que se realizarón durante la investigación, ambiente
cloud en el que se desarrollaron y resultados de las pruebas de lectura y consultas y
de escritura y termina con las conclusiones obtenidas luego del analisis de los
resultados de las pruebas para luego finalizar con las recomendaciones para trabajos
futuros.

9
Capitulo 1: - Fundamentos de la tecnología de Bases de Datos
1.1. Almacenamiento de la información a lo largo del tiempo

1.1.1. Siglo XIX y principios del siglo XX

Herman Hollerith (1860-1929) fue denominado el primer ingeniero estadístico de la historia,
ya que inventó una computadora llamada “Máquina Automática Perforadora de Tarjetas”.
Para hacer el censo de Estados Unidos en 1880 se tardaron 7 años para obtener resultados,
pero Herman Hollerith en 1884 creó la máquina perforadora, con la cual, en el censo de 1890
dio resultados en 2 años y medio, donde se podían obtener datos importantes como número
de nacimientos, población infantil y número de familias. La máquina uso sistemas mecánicos
para procesar la información de las tarjetas y para tabular los resultados.

A diferencia con la máquina de Babbage, que utilizaba unas tarjetas similares, éstas se
centraban en dar instrucciones a la máquina. En el invento de Herman Hollerith, cada
perforación en las tarjetas representaba un número y cada dos perforaciones una letra, cada
tarjeta tenia capacidad para 80 variables. La máquina estaba compuesta por una perforadora
automática y una lectora, la cual por medio de un sistema eléctrico leía los orificios de las
tarjetas, ésta tenía unas agujas que buscaban los orificios y al tocar el plano inferior de
mercurio enviaba por medio del contacto eléctrico los datos a la unidad.

Este invento disparó el desarrollo de la tecnología, la industria de los computadores, abriendo

así nuevas perspectivas y posibilidades hacia el futuro.

1.1.2. Década de 1950.

Se desarrollaron las cintas magnéticas para el almacenamiento de datos, las cuales sirvieron
para suplir las necesidades de información de las nuevas industrias. Con los datos
almacenados en cintas las tareas de procesamiento de datos tales como las nóminas fueron
automatizadas. Consistía en leer datos de una o más cintas y pasar los datos a otra, y también
se podía pasar desde las tarjetas perforadas, simulando un sistema de Backup o Respaldo,
que consiste en hacer una copia de seguridad o copia de respaldo, para guardar en un medio
extraíble la información importante. La nueva cinta a la que se transfiere la información pasa
a ser una cinta maestra. Estas cintas (y los paquetes de tarjetas perforadas) sólo se podían leer

10
secuencial y ordenadamente, requiriendo grandes cantidades de tiempo para las operaciones
sobre ellas.

1.1.3. Década de 1960.

El amplio uso de los discos fijos cambió en gran medida el escenario del procesamiento de
datos, ya que los discos fijos permitieron el acceso directo a los datos, lo que ayudó a ahorrar
tiempo. La ubicación de los datos en disco no era importante, ya que a cualquier posición del
disco se podía acceder en sólo milisegundos. A diferencia de las cintas magnéticas, ya no era
necesaria la secuencialidad. Los discos dieron inicio a las bases de datos, de red y jerárquicas,
pues los programadores con su habilidad de manipulación de estructuras junto con las
ventajas de los discos era posible guardar estructuras de datos como listas y árboles.

Esas bases de datos eran demasiado complejas e inflexibles y sólo podían ser usadas por
personal muy calificado. Aunque para escribir los programas de aplicación se utilizaban
lenguajes de alto nivel se disponía también de instrucciones y de subrutinas especializadas
para tratar las bases de datos que requerían que el programador conociera muchos detalles
del diseño físico, y que hacían que la programación fuera muy compleja. Puesto que los
programas estaban relacionados con el nivel físico, se debían modificar continuamente
cuando se hacían cambios en el diseño y la organización de la base de datos. La preocupación
básica era maximizar el rendimiento.

En esta decada mientras las computadoras crecieron en la velocidad y la capacidad, un

número de sistemas de base de datos de uso general surgió; a mediados de la década de 1960
varios de estos sistemas había entrado en uso comercial. El interés en una norma comenzó a
crecer, y Charles Bachman, autor de uno de esos productos, el almacén de datos integrado
(IDS), fundó el "Grupo de Tareas de base de datos" en CODASYL, el grupo responsable de
la creación y estandarización de COBOL. En 1971, la base de datos del Grupo de Tareas
entregado su nivel, que por lo general se hizo conocido como el "enfoque CODASYL", y
pronto una serie de productos comerciales basados en este enfoque entró en el mercado.

El enfoque CODASYL se basó en la navegación "manual" de un conjunto de datos

vinculados que se formó en una red grande. Las aplicaciones podrían encontrar registros por
uno de tres métodos:

11
 El uso de una clave principal (conocida como clave de la CALC, típicamente
implementado por hash)
 Navegando por las relaciones (llamados juegos) de un registro a otro
 Escanear todos los registros en un orden secuencial

Figura 1.1 Estructura básica del modelo de navegación CODASYL

Sistemas posteriores añadieron estructuras de árboles para proporcionar rutas alternativas de

acceso. Muchas bases de datos CODASYL también añaden un lenguaje de consulta muy
sencillo. Sin embargo, en el recuento final, CODASYL era muy complejo y requiere
entrenamiento y esfuerzo para producir aplicaciones útiles significativa.

IBM también tenía su propio DBMS en 1966, conocido como Sistema de Gestión de la
Información (IMS). IMS era un desarrollo del software escrito para el programa Apolo en el
System / 360. IMS fue generalmente similar en concepto a CODASYL, sino que se utiliza
una jerarquía estricta de su modelo de navegación de datos en lugar del modelo de red de
CODASYL. se accedió a ambos conceptos más tarde se conoció como bases de datos de
navegación debido a la forma de datos, presentación y 1973 Premio Turing de Bachman fue
el programador como Navigator.

12
 1.1.4. Década de 1970.

Edgar Frank Codd, en un artículo "Un modelo relacional de datos para grandes bancos de
datos compartidos" ("A Relational Model of Data for Large Shared Data Banks") en 1970,
definió el modelo relacional y publicó una serie de reglas para la evaluación de
administradores de sistemas de datos relacionales y así nacieron las bases de datos
relacionales.

La simplicidad del modelo relacional y la posibilidad de ocultar completamente los detalles

de implementación al programador fueron realmente atractivas. Codd obtuvo posteriormente
el prestigioso premio Turing de la ACM (Association of Cumputing Machinery, asociación
de la maquinaria informática) por su trabajo. A partir de los aportes de Codd el
multimillonario Larry Ellison desarrolló la base de datos Oracle, el cual es un sistema de
administración de base de datos, que se destaca por sus transacciones, estabilidad,
escalabilidad y multiplataforma.

Figura 1.2 En el modelo relacional, los registros están vinculados con las llaves virtuales que
no están almacenados en la base de datos, pero definidos según sea necesario entre los datos
contenidos en los registros.

13
 1.1.5. Década de 1980.
Inicialmente no se usó el modelo relacional debido a que tenía inconvenientes por el
rendimiento, ya que no podían ser competitivas con las bases de datos jerárquicas y de red.
Esta tendencia cambió por un proyecto de IBM el cual desarrolló técnicas para la
construcción de un sistema de bases de datos relacionales eficientes, llamado System R, un
proyecto en IBM Research que desarrolló técnicas para la construcción de un sistema de
bases de datos relacionales eficiente. Las bases de datos relacionales con su sistema de tablas,
filas y columnas, pudieron competir con las bases de datos jerárquicas y de red incluso en
área de rendimiento, ya que su nivel de programación era bajo y su uso muy sencillo,
reemplazando finalmente a las bases de datos jerárquicas y de red.

Las bases de datos relacionales supusieron un avance importante para facilitar la

programación, realizando automáticamente casi todas las tareas de bajo nivel, liberando al
programador en el nivel lógico. El modelo relacional consiguió el reinado supremo entre
todos los modelos de datos. También en ese tiempo se dio una gran investigación en las bases
de datos paralelas y distribuidas, así como el trabajo inicial en las bases de datos orientadas
a objetos.

1.1.6. Década de 1990.

Al acabar la década de los 80’s, los sistemas de base de datos relacionales ya se utilizaban
prácticamente en todas las empresas.

Para la toma de decisiones se crea el lenguaje SQL (estandarizándose posteriormente), que

es un lenguaje programado para consultas. El programa de alto nivel SQL es un lenguaje de
consulta estructurado que analiza grandes cantidades de información el cual permite
especificar diversos tipos de operaciones frente a la misma información, a diferencia de las
bases de datos de los 80’s que eran diseñadas para las aplicaciones de procesamiento de
transacciones, que eran intensivas en actualizaciones. Los grandes distribuidores de bases de
datos incursionaron con la venta de bases de datos orientada a objetos.

14
El principal acontecimiento a finales de los 90’s fue el crecimiento explosivo de World Wide
Web. Las bases de datos se implantaron mucho más extensivamente que nunca antes. Los
sistemas de bases de datos tienen ahora soporte para tasas de transacciones muy altas, así
como muy alta fiabilidad y disponibilidad 24 horas al día y 7 días a la semana, que significa
que no hay tiempos de inactividad debidos a actividades de mantenimiento planificadas. Los
sistemas de bases de datos también tuvieron interfaces Web a los datos, pues por este medio
se facilitaba su consulta.

1.1.7. Bases de datos en el siglo 21

Hoy día, los sistemas de base de datos relacionales están en plena transformación para
adaptarse a tres tecnologías de éxito reciente, fuertemente relacionadas: la multimedia, la de
orientación a objetos e Internet y la Web.

La rápida adopción de la Web a los sistemas de información hace que los sistemas de base
de datos incorporen recursos para ser servidores de páginas Web, como por ejemplo la
inclusión de SQL en guiones HTML, SQL incorporado en Java, etc. Notando que en el
mundo de la Web son habituales los datos multimedia y la orientación a objetos.

Durante estos últimos años se ha empezado a extender un tipo de aplicación de las bases de
datos denominado Data Warehouse, o almacén de datos, que también produce algunos
cambios en los sistemas de base de datos relacionales del mercado. A lo largo de los años
que han trabajado con bases de datos de distintas aplicaciones, las empresas han ido
acumulando gran cantidad de datos de todo tipo. Si estos datos se analizan convenientemente
pueden dar información valiosa.

Por lo tanto, se trata de mantener una gran base de datos con información proveniente de toda
clase de aplicaciones de la empresa (e incluso de fuera). Los datos de este gran almacén, el
Data Warehouse, se obtienen por una replicación más o menos elaborada de las que hay en
las bases de datos que se utilizan en el trabajo cotidiano de la empresa. Estos almacenes de
datos se utilizan exclusivamente para hacer consultas, de forma especial para que lleven a
cabo estudios los analistas financieros, los analistas de mercado, etc.

15
Actualmente, los sistemas de base de datos relacionales se adaptan a este tipo de aplicación,
incorporando, por ejemplo, herramientas como la creación y el mantenimiento de réplicas
con una cierta elaboración de los datos, la consolidación de datos de orígenes diferentes, la
creación de estructuras físicas que soporten eficientemente el análisis multidimensional, etc.

En los últimos años hubo una gran demanda de bases de datos distribuidas de forma masiva
con alta tolerancia partición pero de acuerdo con el teorema de CAP es imposible para un
sistema distribuido de forma simultánea para proporcionar consistencia, disponibilidad y
tolerancia a la partición garantías. Un sistema distribuido puede satisfacer cualesquiera dos
de estas garantías, al mismo tiempo, pero no los tres. Por esta razón muchas bases de datos
NoSQL están utilizando lo que se llama consistencia eventual para proporcionar una mejor
garantía de disponibilidad y tolerancia a partición con un nivel reducido de consistencia de
los datos. Encontramos dos nuevas vertientes imporrantes:

 Las bases de datos NoSQL son a menudo muy rápido, no requieren esquemas de tablas
fijas, evitar unirse a las operaciones mediante el almacenamiento de datos no
normalizados, y están diseñados para escalar horizontalmente.

 NewSQL es una clase de bases de datos relacionales modernas que pretende ofrecer el
mismo rendimiento escalable de sistemas NoSQL para el procesamiento de transacciones
en línea (lectura y escritura) cargas de trabajo sin dejar de utilizar SQL y el
mantenimiento de las garantías de ácido de un sistema de base de datos tradicional.

1.2. Definición

Se le llama base de datos a los bancos de información que contienen datos relativos a diversas
temáticas y categorizados de distinta manera, pero que comparten entre sí algún tipo de
vínculo o relación que busca ordenarlos y clasificarlos en conjunto.

De este modo una base de datos es un conjunto de datos pertenecientes a un mismo contexto
y almacenados sistemáticamente para su posterior uso.

16
 1.3. ACID

En bases de datos se denomina ACID a las características de los parámetros que permiten
clasificar las transacciones de los sistemas de gestión de bases de datos. Cuando se dice que
es ACID compliant se indica -en diversos grados- que éste permite realizar transacciones.

En concreto ACID es un acrónimo de Atomicity, Consistency, Isolation and Durability:

Atomicidad, Consistencia, Aislamiento y Durabilidad en español.

1.3.1. Requisitos

Cumpliendo estos 4 requisitos un sistema gestor de bases de datos puede ser

considerado ACID Compliant.

1.3.1.1. Atomicidad

Si una operación consiste en una serie de pasos, todos ellos ocurren o ninguno, es decir, las
transacciones son completas.

1.3.1.2. Consistencia

Es la propiedad que asegura que sólo se empieza aquello que se puede acabar. Por lo tanto
se ejecutan aquellas operaciones que no van a romper las reglas y directrices deIntegridad de
la base de datos. La propiedad de consistencia sostiene que cualquier transacción llevará a la
base de datos desde un estado válido a otro también válido. "La Integridad de la Base de
Datos nos permite asegurar que los datos son exactos y consistentes, es decir que estén
siempre intactos, sean siempre los esperados y que de ninguna manera cambien ni se
deformen. De esta manera podemos garantizar que la información que se presenta al usuario
será siempre la misma."

1.3.1.3. Aislamiento

Es la propiedad que asegura que una operación no puede afectar a otras. Esto asegura que la
realización de dos transacciones sobre la misma información sean independientes y no
generen ningún tipo de error. Esta propiedad define cómo y cuándo los cambios producidos
por una operación se hacen visibles para las demás operaciones concurrentes. El aislamiento
puede alcanzarse en distintos niveles, siendo el parámetro esencial a la hora de seleccionar
SGBDs.

17
 1.3.1.4. Durabilidad

Es la propiedad que asegura que una vez realizada la operación, ésta persistirá y no se podrá
deshacer aunque falle el sistema y que de esta forma los datos sobrevivan de alguna manera.

1.4. Clasificación de las bases de datos

Las bases de datos pueden clasificarse de varias maneras, de acuerdo al contexto que se esté
manejando, la utilidad de las mismas o las necesidades que satisfagan.

1.4.1. Según la variabilidad de la base de datos

1.4.1.1. Bases de datos estáticas

Son bases de datos únicamente de lectura, utilizadas primordialmente para almacenar datos
históricos que posteriormente se pueden utilizar para estudiar el comportamiento de un
conjunto de datos a través del tiempo, realizar proyecciones, tomar decisiones y realizar
análisis de datos para inteligencia empresarial.

1.4.1.2. Bases de datos dinámicas

Son bases de datos donde la información almacenada se modifica con el tiempo, permitiendo
operaciones como actualización, borrado y edición de datos, además de las operaciones
fundamentales de consulta. Un ejemplo, puede ser la base de datos utilizada en un sistema de
información de un supermercado.

1.4.2. Según el contenido

1.4.2.1. Bases de datos bibliográficas

Sólo contienen un subrogante (representante) de la fuente primaria, que permite localizarla.

Un registro típico de una base de datos bibliográfica contiene información sobre el autor,
fecha de publicación, editorial, título, edición, de una determinada publicación, etc. Puede
contener un resumen o extracto de la publicación original, pero nunca el texto completo,
porque si no, estaríamos en presencia de una base de datos a texto completo (o de fuentes
primarias —ver más abajo). Como su nombre lo indica, el contenido son cifras o números.
Por ejemplo, una colección de resultados de análisis de laboratorio, entre otras.

18
 1.4.2.2. Bases de datos de texto completo

Almacenan las fuentes primarias, como por ejemplo, todo el contenido de todas las ediciones
de una colección de revistas científicas.

1.4.2.3. Directorios

Un ejemplo son las guías telefónicas en formato electrónico.

Estos directorios se pueden clasificar en dos grandes tipos dependiendo de si son personales
o empresariales (llamadas páginas blancas o amarillas respectivamente)

Los directorios empresariales hay de tres tipos

1. Tienen nombre de la empresa y dirección Ejemplo

2. Contienen teléfono y los más avanzado contienen correo electrónico Ejemplo
3. Contienen datos como facturación o número de empleados además de códigos
nacionales que ayudan a su distinción Ejemplo

Los directorios personales solo hay de un tipo, ya que leyes como la LOPD en España protege
la privacidad de los usuarios pertenecientes al directorio

La búsqueda inversa está prohibida en los directorios personales (a partir de un número de

teléfono saber el titular de la línea)

1.4.2.4. Bases de datos o "bibliotecas" de información química o biológica

Son bases de datos que almacenan diferentes tipos de información proveniente de la química,
las ciencias de la vida o médicas. Se pueden considerar en varios subtipos:

 Las que almacenan secuencias de nucleótidos o proteínas.

 Las bases de datos de rutas metabólicas.
 Bases de datos de estructura, comprende los registros de datos experimentales sobre
estructuras 3D de biomoléculas-
 Bases de datos clínicas.
 Bases de datos bibliográficas (biológicas, químicas, médicas y de otros
campos): PubChem, Medline, EBSCOhost.

19
 1.5. Modelo de bases de datos

Además de la clasificación por la función de las bases de datos, éstas también se pueden
clasificar de acuerdo a su modelo de administración de datos.

Un modelo de datos es básicamente una "descripción" de algo conocido como contenedor de

datos (algo en donde se guarda la información), así como de los métodos para almacenar y
recuperar información de esos contenedores. Los modelos de datos no son cosas físicas: son
abstracciones que permiten la implementación de un sistema eficiente de base de datos; por
lo general se refieren a algoritmos, y conceptos matemáticos.

1.5.1. Modelo jerarquico

En un modelo jerárquico, los datos están organizados en una estructura arbórea (dibujada
como árbol invertido o raíz), lo que implica que cada registro sólo tiene un padre. Las
estructuras jerárquicas fueron usadas extensamente en los primeros sistemas de gestión de
datos de unidad central, como el Sistema IMS por IBM, y ahora se usan para describir la
estructura de documentos XML. Esta estructura permite relaciones 1:N entre los datos, y es
muy eficiente para describir muchas relaciones del mundo real: tablas de contenido,
ordenamiento de párrafos y cualquier tipo de información anidada.

Sin embargo, la estructura jerárquica es ineficiente para ciertas operaciones de base de datos
cuando el camino completo no se incluye en cada registro. Una limitación del modelo
jerárquico es su incapacidad para representar de manera eficiente la redundancia en datos.

En la relación Padre-hijo: El hijo sólo puede tener un padre pero un padre puede tener
múltiples hijos. Los padres e hijos están unidos por enlaces. Todo nodo tendrá una lista de
enlaces a sus hijos.

20
Figura 1.3. Representación del modelo jerarquico

1.5.2. Modelo de red

El modelo de red expande la estructura jerárquica, permitiendo relaciones N:N en una

estructura tipo árbol que permite múltiples padres. Antes de la llegada del modelo relacional,
el modelo en red era el más popular para las bases de datos. Este modelo de red (definido por
la especificación CODASYL) organiza datos que usan en dos construcciones básicas,
registros y conjuntos. Los registros contienen campos que puede estar organizados
jerárquicamente, como en el lenguaje COBOL. Los conjuntos definen relaciones N:N entre
registros: varios propietarios, varios miembros. Un registro puede ser un propietario de varios
conjuntos, y miembro en cualquier número de conjuntos.

El modelo en red es una generalización del modelo jerárquico, en tanto está construido sobre
el concepto de múltiples ramas (estructuras de nivel inferior) emanando de uno o varios
nodos (estructuras de nivel alto), mientras el modelo se diferencia del modelo jerárquico en
que las ramas pueden estar unidas a múltiples nodos. El modelo de red es capaz de representar
la redundancia en datos de una manera más eficiente que en el modelo jerárquico.

Las operaciones del modelo de red se realizan por de navegación: un programa mantiene la
posición actual, y navega entre registros siguiendo las relaciones entre ellos. Los registros
también pueden ser localizados por valores claves.

21
Aunque no es una característica esencial del modelo, las bases de datos en red implementan
sus relaciones mediante punteros directos al disco. Esto da una velocidad de recuperación
excelente, pero penaliza las operaciones de carga y reorganización.

Figura 1.4. Representación del modelo de red

1.5.3. Modelo de Fichero Invertido

En un fichero invertido o de índice invertido, los datos contenidos se usan como claves en
una tabla de consulta (lookup table), y los valores en la tabla se utilizan como punteros a la
localización de cada instancia. Esta es también la estructura lógica de los índices de bases de
datos modernas, los cuales introducen sólo el contenido de algunas columnas en esa tabla de
consulta. El modelo de fichero invertido puede poner los índices en ficheros planos para
acceder a sus registros de manera eficiente.

Implementaciones notables de este modelo de datos la realizó Adabas de Software AG,

aparecida en 1970. Adabas logró una importante base de usuarios y está soportada aún hoy.
En la década de 1980 adoptó el modelo relacional y SQL, manteniendo sus propias
herramientas y lenguajes.

22
 1.5.4. Modelo Relacional

El modelo relacional, para el modelado y la gestión de bases de datos, es un modelo de

datos basado en la lógica de predicados y en la teoría de conjuntos.

Tras ser postuladas sus bases en 1970 por Edgar Frank Codd, de los laboratorios IBM en San
José (California), no tardó en consolidarse como un nuevo paradigma en los modelos de base
de datos.

Su idea fundamental es el uso de relaciones. Estas relaciones podrían considerarse en forma

lógica como conjuntos de datos llamados tuplas. Pese a que esta es la teoría de las bases de
datos relacionales creadas por Codd, la mayoría de las veces se conceptualiza de una manera
más fácil de imaginar, pensando en cada relación como si fuese una tabla que está compuesta
por registros (cada fila de la tabla sería un registro o "tupla") y columnas (también llamadas
"campos").

Es el modelo más utilizado en la actualidad para modelar problemas reales y administrar

datos dinámicamente.

En este modelo todos los datos son almacenados en relaciones, y como cada relación es un
conjunto de datos, el orden en el que estos se almacenen no tiene relevancia (a diferencia de
otros modelos como el jerárquico y el de red). Esto tiene la considerable ventaja de que es
más fácil de entender y de utilizar por un usuario no experto. La información puede ser
recuperada o almacenada por medio de consultas que ofrecen una amplia flexibilidad y poder
para administrar la información.

Este modelo considera la base de datos como una colección de relaciones. De manera simple,
una relación representa una tabla que no es más que un conjunto de filas, cada fila es un
conjunto de campos y cada campo representa un valor que interpretado describe el mundo
real. Cada fila también se puede denominar tupla o registro y a cada columna también se le
puede llamar campo o atributo.

23
Figura 1.5. Representación de una base de datos de acuerdo al modelo relacional

Para manipular la información utilizamos un lenguaje relacional, actualmente se cuenta con

dos lenguajes formales el Álgebra relacional y el Cálculo relacional. El Álgebra relacional
permite describir la forma de realizar una consulta, en cambio, el Cálculo relacional
solamente indica lo que se desea devolver.

1.5.4.1. Esquema

Un esquema contiene la definición de una estructura (generalmente relaciones o tablas de

una base de datos), es decir, determina la identidad de la relación y qué tipo de información
podrá ser almacenada dentro de ella; en otras palabras, el esquema contiene los metadatos de
la relación. Todo esquema constará de:

24
 Nombre de la relación (su identificador).
 Nombre de los atributos (o campos) de la relación y sus dominios; el dominio de un
atributo o campo define los valores permitidos para el mismo, equivalente al tipo de dato
por ejemplo character, integer, date, string...
1.5.4.2. Instancias

Una instancia de manera formal es la aplicación de un esquema a un conjunto finito de datos.

En palabras no tan técnicas, se puede definir como el contenido de una tabla en un momento
dado, pero también es válido referirnos a una instancia cuando trabajamos o mostramos
únicamente un subconjunto de la información contenida en una relación o tabla, como por
ejemplo:

 Ciertos caracteres y números (una sola columna de una sola fila).

 Algunas o todas las filas con todas o algunas columnas
 Cada fila es una tupla. El número de filas es llamado cardinalidad.
 El número de columnas es llamado aridad o grado.

La estructura básica de datos del modelo relacional es la relación (tabla), donde la

información acerca de una determinada entidad (p. ej. "empleado") se almacena en tuplas
(filas), cada una con un conjunto de atributos (columnas). Las columnas de cada tabla
enumeran los distintos atributos de la entidad (el nombre del "empleado", dirección y número
de teléfono, p. ej.), de modo que cada tupla de la relación "empleado" representa un empleado
específico guardando los datos de ese empleado concreto.

Todas las relaciones (es decir, tablas) en una base de datos relacional han de seguir unas
mínimas reglas:

 El orden de los atributos es irrelevante

 No puede haber tuplas repetidas
 Cada atributo sólo puede tener un valor.

Una base de datos puede contener varias tablas, cada una similar al modelo plano. Una de las
fortalezas del modelo relacional es que un valor de atributo coincidente en dos registros
(filas) –en la misma o diferente tabla– implica una relación entre esos dos registros. Es

25
posible también designar uno o un conjunto de atributos como "clave", que permitirá
identificar de manera única una fila en una tabla.

Figura 1.6. Tablas y relaciones en el modelo relacional

Dicha clave que permite identificar de manera unívoca una fila en una tabla se denomina
"clave primaria". Las claves son habitualmente utilizadas para combinar datos de dos o más
tablas. Por ejemplo, una tabla de empleados puede contener una columna denominada
"departamento"", cuyo valor coincida con la clave de una tabla denominada "departamentos".
Las claves son esenciales a la hora de crear índices, que facilitan la recuperación rápidas de
datos de tablas grandes. Una clave puede estar formada por cualquier columna o por una
combinación de varias columnas, denominándose clave compuesta. No es necesario definir
todas las claves por adelantado; una columna puede usarse como clave incluso si no estaba
previsto en origen.

26
Una clave que tenga un significado en el mundo físico (tal como un nombre de persona,
el ISBN de un libro o el número de serie de un coche) a veces se denomina clave "natural".
Si no existe una clave natural viable, se puede asignar un sucedáneo arbitrario (como dar a
una persona un número de empleado). En la práctica la mayor parte de las bases de datos
tienen a la vez claves sucedáneas y naturales, dado que las claves sucedáneas pueden usarse
internamente para crear enlaces íntegros entre filas, mientras que las claves naturales tienen
un uso menos fiable a la hora de buscar o enlazar con otras bases de datos.

El lenguaje de interrogación más común utilizado con las bases de datos relacionales es
el Structured Query Language (SQL).

1.5.4.3. Bases de datos relacionales

La base de datos relacional (BDR) es un tipo de base de datos (BD) que cumple con
el modelo relacional (el modelo más utilizado actualmente para implementar las BD ya
planificadas).

Permite establecer interconexiones o relaciones entre los datos (que están guardados en
tablas), y a través de dichas conexiones relacionar los datos de ambas tablas, de ahí proviene
su nombre: "modelo relacional".

Tras ser postuladas sus bases en 1970 por Edgar Frank Codd, de los laboratorios IBM en San
José (California), no tardó en consolidarse como un nuevo paradigma en los modelos de base
de datos.

Caracteristicas de ellas podemos encontrar que:.

 Una base de datos se compone de varias tablas o relaciones.

 No pueden existir dos tablas con el mismo nombre ni registro.
 Cada tabla es a su vez un conjunto de campos (columnas) y registros (filas).
 La relación entre una tabla padre y un hijo se lleva a cabo por medio de las claves
primarias y claves foráneas (o ajenas).
 Las claves primarias son la clave principal de un registro dentro de una tabla y estas
deben cumplir con la integridad de datos.
 Las claves ajenas se colocan en la tabla hija, contienen el mismo valor que la clave
primaria del registro padre; por medio de estas se hacen las formas relacionales.
27
 1.5.4.3.1. Estructura

La base de datos se organiza en dos marcadas secciones; el esquema y los datos (o instancia).

El esquema es la definición de la estructura de la base de datos y principalmente almacena

los siguientes datos:

 El nombre de cada tabla

 El nombre de cada columna
 El tipo de dato de cada columna
 La tabla a la que pertenece cada columna

Las bases de datos relacionales pasan por un proceso al que se le conoce como normalización
de una base de datos, el resultado de dicho proceso es un esquema que permite que la base
de datos sea usada de manera óptima.

Los datos o instancia es el contenido de la base de datos en un momento dado. Es en sí, el

contenido de todos los registros.

1.5.4.3.2. Elementos

1.5.4.3.2.1. Relaciones

En una BDR, todos los datos se almacenan y se accede a ellos por medio de relaciones
previamente establecidas.

1.5.4.3.2.1.1. Relaciones Base

Las relaciones que almacenan datos son llamadas relaciones base y su implementación es
llamada "tabla".

1.5.4.3.2.1.2. Relaciones derivadas

Otras relaciones no almacenan datos, pero son calculadas al aplicar operaciones relacionales.
Estas relaciones son llamadas relaciones derivadas y su implementación es llamada "vista" o
"consulta". Las relaciones derivadas son convenientes ya que expresan información de varias
relaciones actuando como si fuera una sola tabla.

28
 1.5.4.3.2.2. Restricciones

Una restricción es una limitación que obliga el cumplimiento de ciertas condiciones en la

BD.

Algunas no son determinadas por los usuarios, sino que son inherentemente definidas por el
simple hecho de que la BD sea relacional. Algunas otras restricciones las puede definir el
usuario, por ejemplo, usar un campo con valores enteros entre 1 y 10.

Las restricciones proveen un método de implementar "reglas" en la base de datos.

Las restricciones limitan los datos que pueden ser almacenados en las tablas.

Usualmente se definen usando expresiones que dan como resultado un valor booleano,
indicando si los datos satisfacen la restricción o no.

Las restricciones no son parte formal del modelo relacional, pero son incluidas porque juegan
el rol de organizar mejor los datos. Las restricciones son muy discutidas junto con los
conceptos relacionales.

1.5.4.3.2.3. Dominios

Un dominio describe un conjunto de posibles valores para cierto atributo. Como un dominio
restringe los valores del atributo, puede ser considerado como una restricción.
Matemáticamente, atribuir un dominio a un atributo significa "cualquier valor de este atributo
debe ser elemento del conjunto especificado".

Distintos tipos de dominios son: enteros, cadenas de texto, fecha, no procedurales, etc.

Cada tabla puede tener uno o más campos cuyos valores identifican de forma única cada
registro de dicha tabla, es decir, no pueden existir dos o más registros diferentes cuyos valores
en dichos campos sean idénticos. Este conjunto de campos se llama clave única. Pueden
existir varias claves únicas en una determinada tabla, y a cada una de éstas suele llamársele
candidata a clave primaria.

1.5.4.3.2.4. Llaves

29
 1.5.4.3.2.4.1. Claves primaria

Se llama clave primaria a un campo o a una combinación de campos que identifica de forma
única a cada fila de una tabla. Una clave primaria comprende de esta manera una columna o
conjunto de columnas. No puede haber dos filas en una tabla que tengan la misma clave
primaria.

Una clave primaria debe identificar a todas las posibles filas de una tabla y no únicamente a
las filas que se encuentran en un momento determinado. Ejemplos de claves primarias
son DNI (asociado a unapersona) o ISBN (asociado a un libro). Las guías telefónicas y
diccionarios no pueden usar nombres o palabras o números del sistema decimal de
Dewey como claves candidatas, porque no identifican unívocamente números de teléfono o
palabras.

El modelo relacional, según se lo expresa mediante cálculo relacional y álgebra relacional,

no distingue entre clave primaria y otros tipos de claves. Las claves primarias fueron
agregadas al estándar SQL principalmente para conveniencia del programador. En
una arquitectura entidad-relación, la clave primaria permite las relaciones de la tabla que
tiene la clave primaria con otras tablas que van a utilizar la información de esta tabla.

Tanto claves únicas como claves primarias pueden referenciarse conclaves foráneas.

1.5.4.3.2.4.2. Clave foranea

En el contexto de bases de datos relacionales, una clave foranea (o Foreign Key FK) es una
limitación referencial entre dos tablas.La clave foranea identifica una columna o grupo de
columnas en una tabla(referendo) que se refiere a una columna o grupo de columnas en otra
tabla(referenciada).Las columnas en la tabla referendo deben ser la clave primaria u otra
clave candidata en la tabla referenciada.

Los valores en una fila de las columnas referendo deben existir solo en una fila en la tabla
referenciada.Así, una fila en la tabla referendo no puede contener valores que no existen en
la tabla referenciada.De esta forma, las referencias pueden ser creadas para vincular o
relacionar información. Esto es una parte esencial de la normalización de base de
datos.Múltiples filas en la tabla referendo pueden hacer referencia, vincularse o relacionarse

30
a la misma fila en la tabla referenciada.Mayormente esto se ve reflejado en una relacion uno
(tabla maestra o referenciada) a muchos (tabla hija o referendo).

La tabla referendo y la tabla referenciada pueden ser la misma, esto es, la clave foranea remite
o hace referencia a la misma tabla. Esta clave externa es conocida en SQL:2003 como auto-
referencia o clave foranea recursiva. Una tabla puede tener múltiples claves foraneas y cada
una puede tener diferentes tablas referenciadas. Cada clave foranea es forzada
independientemente por el sistema de base de datos. Por tanto, las relaciones en cascada entre
tablas pueden realizarse usando claves foraneas. Configuraciones impropias de las claves
foraneas o primarias o no forzar esas relaciones son frecuentemente la fuente de muchos
problemas para la base de datos o para el modelamiento de los mismos.

La diferencia entre una llave (o clave) foránea y una primaria es que la foránes procede de
otra tabla dentro de la base de datos, mientras que la primaria hace referencia a un campo de
la tabla con la cual estamos trabajando.

1.5.4.3.2.4.3. Indice

El índice de una base de datos es una estructura de datos que mejora la velocidad de las
operaciones, por medio de identificador único de cada fila de una tabla, permitiendo un
rápido acceso a los registros de una tabla en una base de datos.

El índice tiene un funcionamiento similar al índice de un libro, guardando parejas de

elementos: el elemento que se desea indexar y su posición en la base de datos. Para buscar
un elemento que esté indexado, sólo hay que buscar en el índice dicho elemento para, una
vez encontrado, devolver el registro que se encuentre en la posición marcada por el índice.

Los índices pueden ser creados usando una o más columnas, proporcionando la base tanto
para búsquedas rápidas al azar como de un ordenado acceso a registros eficiente.

Los índices son construidos sobre árboles B, B+, B* o sobre una mezcla de ellos, funciones
de cálculo u otros métodos.

El espacio en disco requerido para almacenar el índice es típicamente menor que el espacio
de almacenamiento de la tabla (puesto que los índices generalmente contienen solamente los

31
campos clave de acuerdo con los que la tabla será ordenada, y excluyen el resto de los detalles
de la tabla), lo que da la posibilidad de almacenar en memoria los índices de tablas que no
cabrían en ella. En una base de datos relacional un índice es una copia de una parte de la
tabla.

Algunas bases de datos amplían la potencia del indexado al permitir que los índices sean
creados de funciones o expresiones. Por ejemplo, un índice puede ser creado sobre la función
upper(apellido), que almacenaría en el índice solamente las versiones mayúsculas del campo
apellido. Otra opción a veces soportada, es el uso de índices "filtrados", donde las entradas
del índice son creadas solamente para los registros que satisfagan una cierta expresión
condicional. Un aspecto adicional de flexibilidad es permitir la indexación en funciones
definidas por el usuario, también como expresiones formadas de un surtido de funciones
incorporadas.

Los índices pueden ser definidos como únicos o no únicos. Un índice único actúa como una
restricción en la tabla previniendo filas idénticas en el índice.

1.5.4.3.2.5. Procedimientos almacenados

Un procedimiento almacenado (stored procedure en inglés) es

unprograma (o procedimiento) almacenado físicamente en una base de datos. Su
implementación varía de un gestor de bases de datos a otro. La ventaja de un procedimiento
almacenado es que al ser ejecutado, en respuesta a una petición de usuario, es ejecutado
directamente en el motor de bases de datos, el cual usualmente corre en un servidor separado.
Como tal, posee acceso directo a los datos que necesita manipular y sólo necesita enviar sus
resultados de regreso al usuario, deshaciéndose de la sobrecarga resultante de comunicar
grandes cantidades de datos salientes y entrantes.

1.5.4.3.2.5.1. Usos

Los usos 'típicos' de los procedimientos almacenados se aplican en la validación de datos,

integrados dentro de la estructura del banco de datos. Los procedimientos
almacenados usados con tal propósito se llaman comúnmente disparadores, o triggers. Otro
uso común es la 'encapsulación' de un API para un proceso complejo o grande que podría

32
requerir la 'ejecución' de varias consultas SQL, tales como la manipulación de un conjunto
de datos enorme para producir un resultado resumido.

También pueden ser usados para el control de gestión de operaciones, y ejecutar

procedimientos almacenados dentro de una transacción de tal manera que las transacciones
sean efectivamente transparentes para ellos.

1.5.5. Modelos Post Relacionales

Los productos que ofrecen un modelo de datos más general que el relacional se denominan
a veces post-relational. Como términos alternativos se oyen incluyen "bases de datos
híbridas", "bases de datos relacionales potenciadas con objetos" entre otros. El modelo de
datos de esos productos incorpora relaciones pero no limitadas por las restricciones del
principio de información de E.F. Codd, que requiere que toda información en la base de datos
debe ser modelada en términos de valores en relaciones nada más

Algunas de estas extensiones al modelo relacional integran conceptos de tecnologías que

preceden el modelo relacional. Por ejemplo permiten representar un grafo dirigido con
árboles en los nodos. La compañía sones implementa este concepto en su GraphDB.

Algunos productos post-relacionales amplían los sistemas relacionales con caracterśiticas no

relacionales. Otros han llegado al mismo punto añadiendo características relacionales a
modelos pre-relacionales. Paradójicamente esto ha permitido a productos históricamente pre-
relacionales, como por ejemplo PICK y MUMPS, razonar su esencia post-relactional.

El Resource Space Model es un modelo de datos no relacional basado en clasificación multi-

dimensional.

1.5.5.1. Modelo de grafo

Las bases de datos de grafos permiten incluso una estructura más general que una base de
datos en red, cualquier nodo puede estar conectado a cualquier otro.

1.5.5.2. Modelo multivaluados

Las bases de datos multivaluadas contienen datos arracimados, en el sentido de que pueden
almacenar los datos del mismo modo que las bases de datos relacionales, pero además
permiten un nivel de profundidad al que las relacionales sólo se pueden aproximar utilizando

33
subtablas. Esto es prácticamente igual al modo en que XML representa los datos, donde un
campo/atributo dado puede contener múltiples valores a la vez. El multivalor se puede
considerar una forma de XML comprimida.

Un ejemplo puede ser una factura, la que puede ser vista como:

 Encabezado, una entrada por factura

 Detalle, una entrada por concepto

El modelo conceptual tiene la ventaja que la correspondencia entre la factura conceptual y la

de la factura como representación de datos es biunívoca. Esto redunda en menor número de
lecturas, menos problemas de integridad referencial y una fuerte disminución
del hardware necesario para soportar un volumen de transacciones dado.

1.5.5.3. Modelo orientado a objetos

En la década de 1990, el paradigma de la orientación a objetos se aplicó a las bases de datos

creando un nuevo modelo llamado base de datos orientada a objetos. Esto tuvo el fin de
reducir la impedancia objeto-relacional, la sobrecarga de convertir la información de su
representación en la base de datos –como filas en tablas– a su representación en el programa
–típicamente como objeto–. Incluso más, los tipos de datos usados en una aplicación pueden
definirse directamente en la base de datos, preservando así la base de datos la misma
integridad de datos. Las bases de datos orientadas a objetos también introducen las ideas
clave de la programación orientada a objetos –encapsulación y polimorfismo– en el mundo
de las bases de datos.

Se han propuesto distintos modos de almacenar objetos en una base de datos. Algunos se han
aproximado desde la prespectiva de la programación, haciendo los objetos manipulados por
el programa persistentes. Esto típicamente requiere la adición de algún tipo de lenguaje de
interrogación, ya que lo lenguajes tradicionales no tienen la posibilidad de encontrar objetos
basados en su contenido. Otros se han proximado al problema desde la prespectiva de la base
de datos, definiendo un modelo orientado a objetos para la base de datos, y definiendo un
lenguaje de programación de dicha base de datos que permite tanto capacidades de
programación como de interrogación.

34
Las bases de datos orientadas a objetos sufren falta de estandarización; aunque han sido
definidos estándares por en Object Database Management Group nunca han sido
implementados con generalidad suficiente como para permitir la interoperatibilidad entre
productos. Sin embargo, las bases de datos orientadas a objetos han sido empleadas
eficazmente en distintas aplicaciones: generalmente en nichos especializados como
ingeniería o biología molecular, pero no de forma general con soporte comercial. Sin
embargo algunas de las ideas que ha aportado han sido recogidas por los fabricantes de bases
de datos relacionales y se han aplicado en extensiones al lenguaje SQL.

Figura 1.6. Representación del modelo orientado a objetos

Una alternativa a la traducción entre objetos y relaciones es la de usar una librería Object-
Relational Mapping (ORM).

35
 1.6. Sistema Gestor de Bases de datos

Un sistema gestor de base de datos (SGBD) es un conjunto de programas que permiten el

almacenamiento, modificación y extracción de la información en una base de datos, además
de proporcionar herramientas para añadir, borrar, modificar y analizar los datos. Los usuarios
pueden acceder a la información usando herramientas específicas de interrogación y de
generación de informes, o bien mediante aplicaciones al efecto.

Estos sistemas también proporcionan métodos para mantener la integridad de los datos, para
administrar el acceso de usuarios a los datos y para recuperar la información si el sistema se
corrompe. Permiten presentar la información de la base de datos en variados formatos. La
mayoría incluyen un generador de informes. También pueden incluir un módulo gráfico que
permita presentar la información con gráficos y tablas.

Hay muchos tipos distintos según cómo manejen los datos y muchos tamaños distintos de
acuerdo a si operan en computadoras personales y con poca memoria o grandes sistemas que
funcionan en mainframes con sistemas de almacenamiento especiales.

Generalmente se accede a los datos mediante lenguajes de interrogación, lenguajes de alto

nivel que simplifican la tarea de construir las aplicaciones. También simplifican la
interrogación y la presentación de la información. Un SGBD permite controlar el acceso a
los datos, asegurar su integridad, gestionar el acceso concurrente a ellos, recuperar los datos
tras un fallo del sistema y hacer copias de seguridad. Las bases de datos y los sistemas para
su gestión son esenciales para cualquier área de negocio, y deben ser gestionados con esmero.

Las características de un Sistema Gestor de Base de Datos SGBD son:

 Abstracción de la información. Los SGBD ahorran a los usuarios detalles acerca del
almacenamiento físico de los datos. Da lo mismo si una base de datos ocupa uno o cientos
de archivos, este hecho se hace transparente al usuario. Así, se definen varios niveles de
abstracción.
 Independencia. La independencia de los datos consiste en la capacidad de modificar el
esquema (físico o lógico) de una base de datos sin tener que realizar cambios en las
aplicaciones que se sirven de ella.

36
 Redundancia mínima. Un buen diseño de una base de datos logrará evitar la aparición de
información repetida o redundante. De entrada, lo ideal es lograr una redundancia nula;
no obstante, en algunos casos la complejidad de los cálculos hace necesaria la aparición
de redundancias.
 Consistencia. En aquellos casos en los que no se ha logrado esta redundancia nula, será
necesario vigilar que aquella información que aparece repetida se actualice de forma
coherente, es decir, que todos los datos repetidos se actualicen de forma simultánea.
 Seguridad. La información almacenada en una base de datos puede llegar a tener un gran
valor. Los SGBD deben garantizar que esta información se encuentra segurizada frente a
usuarios malintencionados, que intenten leer información privilegiada; frente a ataques
que deseen manipular o destruir la información; o simplemente ante las torpezas de algún
usuario autorizado pero despistado. Normalmente, los SGBD disponen de un complejo
sistema de permisos a usuarios y grupos de usuarios, que permiten otorgar diversas
categorías de permisos.
 Integridad. Se trata de adoptar las medidas necesarias para garantizar la validez de los
datos almacenados. Es decir, se trata de proteger los datos ante fallos de hardware, datos
introducidos por usuarios descuidados, o cualquier otra circunstancia capaz de corromper
la información almacenada.
 Respaldo y recuperación. Los SGBD deben proporcionar una forma eficiente de realizar
copias de respaldo de la información almacenada en ellos, y de restaurar a partir de estas
copias los datos que se hayan podido perder.
 Control de la concurrencia. En la mayoría de entornos (excepto quizás el doméstico), lo
más habitual es que sean muchas las personas que acceden a una base de datos, bien para
recuperar información, bien para almacenarla. Y es también frecuente que dichos accesos
se realicen de forma simultánea. Así pues, un SGBD debe controlar este acceso
concurrente a la información, que podría derivar en inconsistencias.

1.6.1. Sistemas integrados

Podemos encontrar que los gestores de bases de datos comparten ciertos sistemas basicos
como lo son:

37
 El motor de la base de datos acepta peticiones lógicas de los otros subsistemas del SGBD,
las convierte en su equivalente físico y accede a la base de datos y diccionario de datos
en el dispositivo de almacenamiento.
 El subsistema de definición de datos ayuda a crear y mantener el diccionario de datos y
define la estructura del fichero que soporta la base de datos.
 El subsistema de manipulación de datos ayuda al usuario a añadir, cambiar y borrar
información de la base de datos y la interroga para extraer información. El subsistema de
manipulación de datos suele ser la interfaz principal del usuario con la base de datos.
Permite al usuario especificar sus requisitos de la información desde un punto de vista
lógico.
 El subsistema de generación de aplicaciones contiene utilidades para ayudar a los
usuarios en el desarrollo de aplicaciones. Usualmente proporciona pantallas de entrada
de datos, lenguajes de programación e interfaces.
 El subsistema de administración ayuda a gestionar la base de datos ofreciendo
funcionalidades como almacenamiento y recuperación, gestión de la seguridad,
optimización de preguntas, control de concurrencia y gestión de cambios.

1.6.2. Arquitectura

La arquitectura de un SGBD especifica sus componentes (incluyendo su descripción

funcional) y sus interfaces. Trata de conceptos distintos que la arquitectura de la base de
datos.

 Interfaces externas: medios para comunicarse con el SGDB en ambos sentidos (E/S) y
explotar a todas sus funciones. Pueden afectar a la BD o a la operación del SGBD, por
ejemplo:
 operaciones directas con la base de datos: definición de tipos, asignación de niveles
de seguridad, actualización de datos, interrogación de la base de datos...
 operaciones relativas a la operación del SGBD: copia de seguridad y restauración,
recuperación tras una caída, monitoreo de seguridad, gestión del almacenamiento,

38
 reserva de espacio, monitoreo de la configuración, monitoreo de prestaciones,
afinado...
 las interfaces externas bien pueden ser utilizadas por usuarios (p. e. administradores)
o bien por programas que se comunican a través de una API.
 Intérprete o procesador del lenguaje: la mayor parte de las operaciones se efectúan
mediante un lenguaje de base de datos. Existen lenguajes para definición de datos,
manipulación de datos (p. e. SQL), para especificar aspectos de la seguridad y más. Las
sentencias en ese lenguaje se introducen en el SGBD mediante la interfaz adecuada. Se
procesan las expresiones en dicho lenguaje (ya sea compilado o interpretado) para extraer
las operaciones de modo que puedan ser ejecutadas por el SGBD.
 Optimizador de consultas: realiza la optimización de cada pregunta y escoge el plan de
actuación más eficiente para ejecutarlo.
 Motor de la base de datos: realiza las operaciones requeridas sobre la base de datos,
típicamente representándolo a alto nivel.
 Mecanismo de almacenamiento: traduce las operaciones a lenguaje de bajo nivel para
acceder a los datos. En algunas arquitecturas el mecanismo de almacenamiento está
integrado en el motor de la base de datos.
 Motor de transacciones: para conseguir corrección y fiabilidad, la mayoría de las
operaciones internas del SGBD, se realizan encapsuladas dentro de transacciones. Las
transacciones pueden ser especificadas externamente al SGBD para encapsular un grupo
de operaciones. El motor de transacciones sigue la ejecución de las transacciones y
gestiona su ejecución de acuerdo con las reglas que tiene establecidas (p. e., control de
concurrencia y su ejecución o cancelación).
 Gestión y operación de SGBD: comprende muchos otros componentes que tratan de
aspectos de gestión y operativos del SGBD como monitoreo de prestaciones, gestión del
almacenamiento, mapas de almacenamiento.

1.7. Bases de Datos NoSQL

NoSQL (a veces llamado "no sólo SQL") es una amplia clase de sistemas de gestión de bases
de datos que difieren del modelo clásico del sistema de gestión de bases de datos relacionales

39
(RDBMS) en aspectos importantes, el más destacado es que no usan SQL como el principal
lenguaje de consultas. Los datos almacenados no requieren estructuras fijas como tablas,
normalmente no soportan operacionesJOIN, ni garantizan
completamente ACID (atomicidad, consistencia, aislamiento y durabilidad), y habitualmente
escalan bien horizontalmente. Los sistemas NoSQL se denominan a veces "no sólo SQL"
para subrayar el hecho de que también pueden soportar lenguajes de consulta de tipo SQL.

Por lo general, los investigadores académicos se refieren a este tipo de bases de datos
como almacenamiento estructurado, término que abarca también las bases de datos
relacionales clásicas. A menudo, las bases de datos NoSQL se clasifican según su forma de
almacenar los datos, y comprenden categorías como clave-valor, las implementaciones de
BigTable, bases de datos documentales, y Bases de datos orientadas a grafos.

Los sistemas de bases de datos NoSQL crecieron con las principales compañías de Internet,
como Google, Amazon, Twitter y Facebook. Estas tenían que enfrentarse a desafíos con el
tratamiento de datos que las tradicionales RDBMS no solucionaban . Con el crecimiento de
la web en tiempo real existía una necesidad de proporcionar información procesada a partir
de grandes volúmenes de datos que tenían unas estructuras horizontales más o menos
similares. Estas compañías se dieron cuenta de que el rendimiento y sus propiedades de
tiempo real eran más importantes que la coherencia, en la que las bases de datos relacionales
tradicionales dedicaban una gran cantidad de tiempo de proceso

En ese sentido, a menudo, las bases de datos NoSQL están altamente optimizadas para las
operaciones recuperar y agregar, y normalmente no ofrecen mucho más que la funcionalidad
de almacenar los registros (p.ej. almacenamiento clave-valor). La pérdida de flexibilidad en
tiempo de ejecución, comparado con los sistemas SQL clásicos, se ve compensada por
ganancias significativas en escalabilidad y rendimiento cuando se trata con ciertos modelos
de datos.

1.7.1. Caracteristicas

 Consistencia Eventual: No se implementan mecanismos rígidos de consistencia como

los presentes en las bases de datos relacionales, donde la confirmación de un cambio

40
 implica una comunicación del mismo a todos los nodos que lo repliquen. Esta
flexibilidad hace que la consistencia se dé, eventualmente, cuando no se hayan
modificado los datos durante un periodo de tiempo. Esto se conoce también
como BASE (Basically Available Soft-state Eventual Consistency, o coherencia
eventual flexible básicamente disponible).
 Estructura distribuida: Generalmente se distribuyen los datos mediante mecanismos
de tablas de hash distribuidas.
 Escalabilidad horizontal: Consite en la posibilidad de aumentar el rendimiento del
sistema simplemente añadiendo más nodos, sin necesidad en muchos casos de realizar
ninguna otra operación más que indicar al sistema cuáles son los nodos disponibles.
Muchos sistemas NoSQL permiten utilizar consultas del tipo Map-Reduce, las cuales
pueden ejecutarse en todos los nodos a la vez (cada uno operando sobre una porción
de los datos) y reunir luego los resultados antes de devolverlos.
 Tolerancia a fallos y Redundancia.
 No generan cuellos de botella: el problema de fondo de los sistemas SQL, es que
deben de transcribir cada sentencia para poder ser ejecutada y, cada sentencia
compleja requiere, además de un nivel de ejecución más concreto para poderse llevar
a cabo, por lo que constituye un punto de entrada común, único y conflictivo en base
a rendimiento.
 Solo lo estrictamente necesario: son sistemas simples que no tienen un sistema de
consulta complejo ni con capacidad declarativa para en una sola línea realizar una
cantidad interna de operaciones desorbitada.
 Estructura dinámica: La primera característica significa que los datos no tienen una
definición de atributos fija, es decir: Cada registro puede contener una información
con diferente forma cada vez, pudiendo así almacenar sólo los atributos que interesen
en cada uno de ellos, facilitando el polimorfismo de datos bajo una misma colección
de información. También se pueden almacenar estructuras de datos complejas en un
sólo documento, como por ejemplo almacenar la información sobre una publicación
de un blog (título, cuerpo de texto, autor, etc) junto a los comentarios y etiquetas
vertidos sobre el mismo, todo en un único registro. Hacerlo así aumenta la claridad
(al tener todos los datos relacionados en un mismo bloque de información) y el

41
 rendimiento (no hay que hacer un JOIN para obtener los datos relacionados, pues
éstos se encuentran directamente en el mismo documento).

1.7.2. BASE

Las Bases de Datos NoSQL son repositorios de almacenamiento más optimistas, pues siguen
el modelo BASE:
 Basic availability. El almacén funciona la mayoría del tiempo incluso ante fallos
gracias al almacenamiento distribuido y replicado.
 Soft-sate. Los almacenes no tienen porque ser consistentes ni sus réplicas en todo
momento. El programador puede verificar esa consistencia.
 Eventual consistency. La consistencia que se da eventualmente.
BASE es una alternativa flexible a ACID para aquellos almacenes de datos que no requieren
un adherencia estricta a las transacciones.

1.7.3. Tipos de bases de datos NoSQL

En general hay 5 tipos de bases de datos NoSQL, dependiendo de como almacenan la

información:

 Key-Value: clave-valor es la forma mas típica, como un HashMap donde cada

elemento esta identificado por una llave única, lo que permite la recuperación de la
información de manera muy rápida. Normalmente el valor se alamcenar como un
objeto BLOB. De esta forma el tipo de contenido no es importante para la base de
datos, solo la clave y el valor que tiene asociado. Son muy eficientes para lecturas y
escrituras, además de que pueden escalar fácilmente particionando los valores de
acuerdo a su clave; por ejemplo aquellos cuya clave está entre 1 y 1000 van a un
server, los de 1001 a 2000 a otro, etc. Muchas de ellas están basadas en la publicación
de Google acerca de su BigTable y de Amazon. Dentro de estas bases de datos
podemos encontrar a BigTable de Google, SimpleDB de Amazon,
Cassandra, Hadoop, Riak, Voldemort yMemcacheDB entre otras.

42
 Basada en Documentos: estas almacenan la información como un documento
(generalmente con una estructura simple como JSON o XML) y con una clave única.
Es similar a las bases de datos Key-value, pero con la diferencia que el valor es un
fichero que puede ser entendido. Si el servidor entiende los datos, puede hacer
operaciones con ellos. De hecho varias de las implementaciones de este tipo de bases
de datos permiten consultas muy avanzadas sobre los datos, e incluso establecer
relaciones entre ellos, aunque siguen sin permitir joins. Podemos encontrar a
MongoDB y CouchDB entre las mas importantes de este tipo.
 Orientadas a Grafos: Hay otras bases de datos que almacenan la información como
grafos donde las relaciones entre los nodos son lo mas importante. Son muy útiles
para representar información de redes sociales. De hecho, las relaciones también
pueden tener atributos y puedes hacer consultas directas a relaciones, en vez de a los
nodos. Además, al estar almacenadas de esta forma, es mucho más eficiente navegar
entre relaciones que en un modelo relacional. Obviamente, este tipo de bases de datos
sólo son aprovechables si la información en cuestión se puede representar fácilmente
como una red.Encontramos a neo4j entre otras.
 Orientadas a Columnas: guardan los valores en columnas en lugar de filas. Con este
cambio ganamos mucha velocidad en lecturas, ya que si se requiere consultar un
número reducido de columnas, es muy rápido hacerlo pero no es eficiente para
realizar escrituras. Por ello este tipo de soluciones es usado en aplicaciones con un
índice bajo de escrituras pero muchas lecturas. Por ejemplo, Cassandra.

43
Capitulo 2: - Computación en la nube
2.1. ¿Qué es la computación en la nube?
La computación en la nube conocida también como servicios en la nube, informática en la
nube, nube de cómputoo nube de conceptos (del inglés cloud computing), es
un paradigma que permite ofrecer servicios de computación a través de una red, que
usualmente es Internet.

El concepto de la computación en la nube empezó en proveedores de servicio de Internet a

gran escala, como Google, Amazon AWS, Microsoft y otros que construyeron su propia
infraestructura. De entre todos ellos emergió una arquitectura: un sistema de recursos
distribuidos horizontalmente, introducidos como servicios virtuales de TI escalados
masivamente y manejados como recursos configurados y mancomunados de manera
continua. Este modelo de arquitectura fue inmortalizado por George Gilder en su artículo de
octubre 2006 en la revista Wired titulado «Las fábricas de información». Las granjas de
servidores, sobre las que escribió Gilder, eran similares en su arquitectura al procesamiento
“grid” (red, parrilla), pero mientras que las redes se utilizan para aplicaciones de
procesamiento técnico débilmente acoplados (loosely coupled), un sistema compuesto de
subsistemas con cierta autonomía de acción, que mantienen una interrelación continua entre
ellos, este nuevo modelo de nube se estaba aplicando a los servicios de Internet.

Esta revolución está ofreciendo a las empresas un gran ahorro de costes ya que elimina las
inversiones iniciales (Capex) y las convierte en gastos variables muy reducidos según el
consumo (Opex).

2.2. La nube informatica en los ultimos años

El concepto fundamental de la entrega de los recursos informáticos a través de una red global
tiene sus raíces en los años sesenta. La idea de una "red de computadoras intergaláctica" la
introdujo en los años sesenta JCR Licklider, cuya visión era que todo el mundo pudiese estar
interconectado y poder acceder a los programas y datos desde cualquier lugar,
según Margaret Lewis, directora de mercadotecnia de producto de AMD. "Es una visión que
se parece mucho a lo que llamamos cloud computing."

44
Otros expertos atribuyen el concepto científico de la computación en nube a John McCarthy,
quien propuso la idea de la computación como un servicio público, de forma similar a las
empresas de servicios que se remontan a los años sesenta. En 1960 dijo: "Algún día la
computación podrá ser organizada como un servicio público."

Desde los años sesenta, la computación en nube se ha desarrollado a lo largo de una serie de
líneas. La Web 2.0 es la evolución más reciente. Sin embargo, como Internet no empezó a
ofrecer ancho de banda significativo hasta los años noventa, la computación en la nube ha
sufrido algo así como un desarrollo tardío. Uno de los primeros hitos de la computación en
nube es la llegada de Salesforce.com en 1999, que fue pionero en el concepto de la entrega
de aplicaciones empresariales a través de una página web simple. La firma de servicios allanó
el camino para que tanto especialistas como empresas tradicionales de software pudiesen
publicar sus aplicaciones a través de Internet.

El siguiente desarrollo fue Amazon Web Services en 2002, que prevé un conjunto de
servicios basados en la nube, incluyendo almacenamiento, computación e incluso la
inteligencia humana a través del Amazon Mechanical Turk. Posteriormente en 2006,
Amazon lanzó su Elastic Compute Cloud (EC2) como un servicio comercial que permite a
las pequeñas empresas y los particulares alquilar equipos en los que se ejecuten sus propias
aplicaciones informáticas.

"Amazon EC2/S3 fue el que ofreció primero servicios de infraestructura en la nube

totalmente accesibles”, según Jeremy Allaire, CEO de Brightcove, que proporciona su
plataforma SaaS de vídeo en línea a las estaciones de televisión de Reino Unido y
periódicos. George Gilder dijo en 2006: "El PC de escritorio está muerto. Bienvenido a la
nube de Internet, donde un número enorme de instalaciones en todo el planeta almacenarán
todos los datos que usted podrá usar alguna vez en su vida."

Otro hito importante se produjo en 2009, cuando Google y otros empezaron a ofrecer
aplicaciones basadas en navegador. "La contribución más importante a la computación en
nube ha sido la aparición de 'aplicaciones asesinas' de los gigantes de tecnología como
Microsoft y Google. Cuando dichas compañías llevan a cabo sus servicios de una manera
que resulta segura y sencilla para el consumidor, el efecto 'pasar la pelota' en sí crea un

45
sentimiento de mayor aceptación de los servicios online”, según Dan Germain, jefe de la
oficina de tecnología en IT proveedor de servicios Cobweb Solutions.

Otro de los factores clave que han permitido evolucionar a la computación en la nube han
sido, según el pionero en computación en la nube británico Jamie Turner, las tecnologías de
virtualización, el desarrollo del universal de alta velocidad de ancho de banda y normas
universales de interoperabilidad de software. Turner añadió: "A medida que la computación
en nube se extiende, su alcance va más allá de un puñado de usuarios de Google Docs. Sólo
podemos empezar a imaginar su ámbito de aplicación y alcance. Casi cualquier cosa puede
ser utilizado en la nube".

2.3. Caracteristicas principales

 La computación en nube presenta las siguientes características clave:

 Agilidad: Capacidad de mejora para ofrecer recursos tecnológicos al usuario por parte
del proveedor.
 Costo: los proveedores de computación en la nube afirman que los costos se reducen.
Un modelo de prestación pública en la nube convierte los gastos de capital en gastos
de funcionamiento. Ello reduce barreras de entrada, ya que la infraestructura se
proporciona típicamente por una tercera parte y no tiene que ser adquirida por una
sola vez o tareas informáticas intensivas infrecuentes.
 Escalabilidad y elasticidad: aprovisionamiento de recursos sobre una base de
autoservicio en casi en tiempo real, sin que los usuarios necesiten cargas de alta
duración.
 Independencia entre el dispositivo y la ubicación: permite a los usuarios acceder a los
sistemas utilizando un navegador web, independientemente de su ubicación o del
dispositivo que utilice (por ejemplo, PC, teléfono móvil).
 La tecnología de virtualización permite compartir servidores y dispositivos de
almacenamiento y una mayor utilización. Las aplicaciones pueden ser fácilmente
migradas de un servidor físico a otro.

46
  Rendimiento: Los sistemas en la nube controlan y optimizan el uso de los recursos de
manera automática, dicha característica permite un seguimiento, control y
notificación del mismo. Esta capacidad aporta transparencia tanto para el consumidor
o el proveedor de servicio.
 Seguridad: puede mejorar debido a la centralización de los datos. La seguridad es a
menudo tan buena o mejor que otros sistemas tradicionales, en parte porque los
proveedores son capaces de dedicar recursos a la solución de los problemas de
seguridad que muchos clientes no pueden permitirse el lujo de abordar. El usuario de
la nube es responsable de la seguridad a nivel de aplicación. El proveedor de la nube
es responsable de la seguridad física.
 Mantenimiento: en el caso de las aplicaciones de computación en la nube, es más
sencillo, ya que no necesitan ser instalados en el ordenador de cada usuario y se puede
acceder desde diferentes lugares.

2.4. Servicios ofrecidos

2.4.1. Software como servicio
Abreviado como ScuS (del inglés: Software as a Service, SaaS) es un modelo de distribución
de software donde el soporte lógico y los datos que maneja se alojan en servidores de una
compañía de tecnologías de información y comunicación (TIC), a los que se accede
vía Internet desde un cliente. La empresa proveedora TIC se ocupa del servicio de
mantenimiento, de la operación diaria y del soporte del software usado por el cliente.
Regularmente el software puede ser consultado en cualquier computador, se encuentre
presente en la empresa o no. Se deduce que la información, el procesamiento, los insumos, y
los resultados de la lógica de negocio del software, están hospedados en la compañía de TIC.

Las características del software como servicio incluyen:

 Acceso y administración a través de una red.

 Actividades gestionadas desde ubicaciones centrales, en lugar de la sede de cada cliente,
permitiéndoles tener acceso remoto a las aplicaciones a través de la web.

47
 La distribución de la aplicación es más cercana al modelo uno a muchos (una instancia
con múltiples usuarios) que al modelo uno a uno, incluyendo arquitectura, precios,
colaboración, y administración.
 Actualizaciones centralizadas, lo cual elimina la necesidad de descargar parches por parte
de los usuarios finales.
 Frecuente integración con una red mayor de software de comunicación, bien como parte
de un mashup o como un enlace para una plataforma como servicio.

2.4.1.1. Ventajas

 No es necesario que el cliente cuente con un área especializada de soporte para el

sistema, por lo que se reducen sus costes y riesgo de inversión.
 La responsabilidad de la operación recae en la empresa IT. Esto significa que la
garantía de disponibilidad de la aplicación y su correcta funcionalidad, es parte del
servicio que da la compañía proveedora del software.
 La empresa IT no desatiende al cliente. El servicio y atención continua del proveedor
al cliente es necesaria para que este último siga pagando el servicio.
 La empresa IT provee los medios seguros de acceso en los entornos de la aplicación.
Si una empresa IT quiere dar SaaS en su cartera de productos, debe ofrecer accesos
seguros para que no se infiltren datos privados en la red pública.
 No es necesaria la compra de una licencia para utilizar el software, sino el pago de
un alquiler o renta por el uso del software. Aunque también se dan casos particulares
donde el servicio es totalmente gratuito, como por ejemplo en el servicio de blogs que
brindan diferentes compañías: Wordpress, Blogger, etc; es decir, se cuenta con el
servicio, se puede acceder libremente, se garantiza usabilidad y actualidad, pero no
se paga por el servicio.
 Se le permite al cliente completa flexibilidad en el uso de los sistemas operativos de
su preferencia, o al cual pueda tener acceso.

48
2.4.1.2. Inconvenientes

 La persona usuaria no tiene acceso directo a sus contenidos, ya que están guardados
en un lugar remoto, salvo que el sistema prevea la exportación de los datos, (Google,
por ejemplo, permite descargar los correos a una computadora) y en caso de no contar
con mecanismos de cifrado y control disminuye el índice de privacidad, control y
seguridad que ello supone, ya que la compañía TI podría consultarlos.
 El usuario no tiene acceso al programa, por lo cual no puede hacer modificaciones
(dependiendo de la modalidad del contrato de servicios que tenga con la compañía
TI).
 Al estar el servicio y el programa dependientes de la misma empresa, no permite al
usuario migrar a otro servicio utilizando el mismo programa (dependiendo de la
modalidad del contrato de servicios con la compañía de TI).
 Si el servicio de Internet no está disponible por parte del ISP, el usuario no tendrá
acceso al programa, por lo que sus operaciones se verán afectadas hasta que dicho
servicio se restablezca.
 Las desventajas son propias de la cultura instalada de que es mejor tener los datos en
mi computadora, la tendencia indica que esto desaparecerá.

2.4.2. Plataforma como servicio

La capa del medio, que es la plataforma como servicio (en inglés platform as a service, PaaS),
es la encapsulación de una abstracción de un ambiente de desarrollo y el empaquetamiento
de una serie de módulos o complementos que proporcionan, normalmente, una funcionalidad
horizontal (persistencia de datos, autenticación, mensajería, etc.). De esta forma, un arquetipo
de plataforma como servicio podría consistir en un entorno conteniendo una pila básica de
sistemas, componentes o APIs preconfiguradas y listas para integrarse sobre una tecnología
concreta de desarrollo (por ejemplo, un sistema Linux, un servidor web, y un ambiente de
programación como Perl o Ruby). Las ofertas de PaaS pueden dar servicio a todas las fases
del ciclo de desarrollo y pruebas del software, o pueden estar especializadas en cualquier área
en particular, tal como la administración del contenido.

49
En este modelo de servicio al usuario se le ofrece la plataforma de desarrollo y las
herramientas de programación por lo que puede desarrollar aplicaciones propias y controlar
la aplicación, pero no controla la infraestructura.

2.4.3. Infraestructura como servicio

La infraestructura como servicio (infrastructure as a service, IaaS) -también llamada en
algunos casos hardware as a service, HaaS) se encuentra en la capa inferior y es un medio de
entregar almacenamiento básico y capacidades de cómputo como servicios estandarizados
en la red. Servidores, sistemas de almacenamiento, conexiones, enrutadores, y otros sistemas
se concentran (por ejemplo a través de la tecnología de virtualización) para manejar tipos
específicos de cargas de trabajo —desde procesamiento en lotes (“batch”) hasta aumento de
servidor/almacenamiento durante las cargas pico. El ejemplo comercial mejor conocido
es Amazon Web Services, cuyos servicios EC2 y S3 ofrecen cómputo y servicios de
almacenamiento esenciales (respectivamente). Otro ejemplo es Joyent, cuyo producto
principal es una línea de servidores virtualizados, que proveen una infraestructura en
demanda altamente escalable para manejar sitios web, incluidas aplicaciones web complejas
escritas en Python, Ruby, PHP yJava.

50
Figura 2.1. Modelos de IaaS, PaaS y SaaS en donde se muestra la parte gestionada por el
proveedor y la parte gestionada por el usuario.

2.5. Clasificación de la Nube

Dentro de la meetodologia de nube podemos clasificarla de la siguiente forma:

 Nube Publica es una nube computacional mantenida y gestionada por terceras personas
no vinculadas con la organización. En este tipo de nubes tanto los datos como los
procesos de varios clientes se mezclan en los servidores, sistemas de almacenamiento y
otras infraestructuras de la nube. Los usuarios finales de la nube no conocen qué trabajos
de otros clientes pueden estar corriendo en el mismo servidor, red, sistemas de
almacenamiento, etc. Aplicaciones, almacenamiento y otros recursos están disponibles
al público a través de el proveedor de servicios, que es propietario de toda la
infraestructura en sus centros de datos; el acceso a los servicios sólo se ofrece de manera
remota, normalmente a través de internet.

 Nube Privada son una buena opción para las compañías que necesitan alta protección de
datos y ediciones a nivel de servicio. Las nubes privadas están en una infraestructura bajo
demanda, gestionada para un solo cliente que controla qué aplicaciones debe ejecutarse
y dónde. Son propietarios del servidor, red, y disco y pueden decidir qué usuarios están
autorizados a utilizar la infraestructura. Al administrar internamente estos servicios, las
empresas tienen la ventaja de mantener la privacidad de su información y permitir
unificar el acceso a las aplicaciones corporativas de sus usuarios.

 Nube Hibrida combinan los modelos de nubes públicas y privadas. Un usuario es

propietario de unas partes y comparte otras, aunque de una manera controlada. Las nubes
híbridas ofrecen la promesa del escalado, aprovisionada externamente, a demanda, pero
añaden la complejidad de determinar cómo distribuir las aplicaciones a través de estos
ambientes diferentes. Las empresas pueden sentir cierta atracción por la promesa de una
nube híbrida, pero esta opción, al menos inicialmente, estará probablemente reservada a
aplicaciones simples sin condicionantes, que no requieran de ninguna sincronización o

51
 necesiten bases de datos complejas. Se unen mediante la tecnología, pues permiten enviar
datos o aplicaciones entre ellas. Un ejemplo son los sistemas de correo electrónico
empresarial.

 Nube comunitaria. De acuerdo con Joyanes Aguilar en 2012 el Instituto Nacional de

Estándares y Tecnología (NITS, por sus siglas en inglés) define este modelo como aquel
que se organiza con la finalidad de servir a una función o propósito común (seguridad,
política…), las cuales son administradas por las organizaciones constituyentes o terceras
partes.

2.6. Aspectos de seguridad

La seguridad en la computación en la nube puede ser tan buena o mejor que la que existía en
los sistemas tradicionales, porque los proveedores son capaces de proporcionar recursos que
resuelvan problemas de seguridad que muchos clientes no pueden afrontar. Sin embargo, la
seguridad todavía sigue siendo un asunto importante, cuando los datos tienen un matiz
confidencial. Esto atrasa la adopción de la computación en la nube hasta cierto punto.

Seguridad como servicio

En el entorno de la nube, la seguridad es provista por los proveedores. Se pueden distinguir

dos métodos: El primer método, es que cualquiera puede cambiar sus métodos de entrega
incluidos en los servicios de la nube. El segundo método es que los proveedores de servicio
de la nube proveen seguridad solo como servicio en la nube, con información de seguridad
de las compañías.

Seguridad del explorador

En el entorno de la nube, los servidores remotos son usados para la computación. Los nodos
del cliente se usan solo para entrada/salida de operaciones, y para la autorización y
autenticación de la información en la nube. Un navegador web estándar es una plataforma
normalmente utilizada para todos los usuarios del mundo. Esto puede ser catalogado en dos
tipos diferentes: Software como servicio (SaaS), Aplicaciones Web, o Web 2.0. Transport
Layer Security (TLS), se suele emplear para la encriptación de datos y la autentificación del
host.

52
Autenticación

En el entorno de la nube, la base para el control de acceso es la autenticación, el control de

acceso es más importante que nunca desde que la nube y todos sus datos son accesibles para
todo el mundo a través de internet. Trusted Platform Module (TPM) es extensamente
utilizado y un sistema de autenticación más fuerte que el nombre de usuario y la contraseña.
Trusted Computing Groups (TCG’s) es un estándar sobre la autorización de usuarios y otras
herramientas de seguridad de comunicación en tiempo real entre el proveedor y el cliente.

Pérdida de gobernanza

En las infraestructuras de la nube, el cliente necesariamente cede el control al proveedor

(cloud provider) en varios asuntos, los cuales influyen negativamente sobre la seguridad. Al
mismo tiempo, el acuerdo de nivel de servicio no suele tener el cometido de surtir este tipo
de servicios en la parte del proveedor de la nube, lo que deja una brecha en las defensas de
seguridad.

Lock-In

Esta es una pequeña oferta en este tipo de herramientas, los procedimientos o estándares de
formatos de datos o interfaces de servicios que podrían garantizar los datos, las aplicaciones
y el servicio de portabilidad. Esto puede hacer difícil para el cliente migrar de un proveedor
a otro, o migrar los datos y servicios de nuevo a otro entorno informático. Esto introduce una
particular dependencia en el proveedor de la nube para la provisión del servicio,
especialmente a la portabilidad de los datos, el aspecto más fundamental.

Protección de los datos

La computación en la nube pone en riesgo la protección de datos para los usuarios de la nube
y sus proveedores. En muchos casos, ocasiona dificultades para el proveedor (en el rol del
controlador de la información) para asegurar la efectividad práctica del manejo de los datos
del proveedor de la nube y para cerciorar que los datos van por el camino correcto. Este
problema se suele agravar en casos de múltiples transferencias de datos, por ejemplo entre
sistemas federados. Por otra parte, algunos proveedores de la nube, proporcionan
información de sus prácticas de cercenamiento de datos. También hay algunas ofertas de
certificaciones en el procesamiento de datos, las actividades de seguridad, y los controles de

53
datos que tienen lugar; ejemplo, la certificación SAS70. Las corrientes de datos de Internet
están unidas al malware y de paquetes señuelo para meter al usuario en una desconocida
participación en actividades delictivas.

2.7. Limitaciones

Algunas limitaciones que están retrasando un poco a la computación en la nube son algunas
de las siguientes:

Pérdidas de datos/fuga

Los esfuerzos para controlar la seguridad de los datos de la computación en la nube no son
muy buenos; acordadamente con el acceso de control API y la generación de las claves,
almacenamiento y configuración de deficiencias, permiten resultados en pérdidas de datos, y
también permiten una escasa política de destrucción de datos. La fuga, es la causa de la escasa
vital política de destrucción de datos.

Dificultad de valorar la fiabilidad de los proveedores

El proveedor de servicio de computación en la nube, controla la fuerza con la que se pueden

realizar los esfuerzos, que actualmente se solían usar para controlar los accesos a los datos,
los cuáles son diferentes en muchos proveedores y en estas circunstancias; pero no todo es
suficiente, las compañías necesitan una evaluación de los proveedores y proponer qué y cómo
filtran el programa personal.

Fuerza de los mecanismos de autentificación

En la nube, hay muchísimos datos, aplicaciones y recursos almacenados. La computación en

la nube es muy débil en los mecanismos de autentificación, por lo tanto el atacante puede
fácilmente obtener la cuenta de usuario cliente y acceder a la máquina virtual.

2.8. Microsoft Azure

Microsoft Azure (anteriormente Windows Azure y Azure Services Platform) es una
plataforma ofrecida como servicio y alojada en los Data Centers de Microsoft.

54
Windows Azure es una plataforma general que tiene diferentes servicios para aplicaciones,
desde servicios que alojan aplicaciones en alguno de los centros de procesamiento de datos
de Microsoft para que se ejecute sobre su infraestructura (Cloud Computing) hasta servicios
de comunicación segura y federación entre aplicaciones.

Figura 2.2 Portal de administración de Microsoft Azure

Dentro de la plataforma, el servicio de Windows Azure es el encargado de proporcionar el

alojamiento de las aplicaciones y el almacenamiento no relacional. Dichas aplicaciones
deben funcionar sobre Windows Server 2008 R2. Pueden estar desarrolladas
en .NET, PHP, C++, Ruby, Java. Además del servicio de ejecución, dispone de diferentes
mecanismos de almacenamiento de datos: tablas NoSQL, blobs, blobs para streaming, colas
de mensajes o 'drives' NTFS para operaciones de lectura / escritura a disco.

2.8.1. Implementación
Windows Azure utiliza un sistema operativo especializado, llamado de la misma forma, para
correr sus "capas" (en inglés “fabric layer”) — un cluster localizado en los servidores de
datos de Microsoft que se encargan de manejar los recursos almacenados y procesamiento
para proveer los recursos(o una parte de ellos) para las aplicaciones que se ejecutan sobre
Windows Azure.

55
Windows Azure se describe como una “capa en la nube” (en inglés "cloud layer")
funcionando sobre un número de sistemas que utilizan Windows Server, estos funcionan bajo
la versión 2008 de Windows Server y una versión personalizada de Hyper-V, conocido como
el Hipervisor de Windows Azure que provee la virtualización de los servicios. La capa
controladora de Windows Azure se encarga de escalar y de manejar la confiabilidad del
sistema evitando así que los servicios se detengan si alguno de los servidores de datos de
Microsoft tiene problemas y a su vez maneja la información de la aplicación web del usuario
dando como ejemplo los recursos de la memoria o el balanceo del uso de esta.

2.8.2. Caracterisiticas de Azure

 Proceso: el servicio de proceso de Windows Azure ejecuta aplicaciones basadas

en Windows Server. Estas aplicaciones se pueden crear mediante .NET Framework en
lenguajes como C# y Visual Basic, o implementar sin .NET en C++, Java y otros
lenguajes.
 Almacenamiento: objetos binarios grandes (blobs) proporcionan colas para la
comunicación entre los componentes de las aplicaciones de Windows Azure y ofrece un
tipo de tablas con un lenguaje de consulta simple.
 Servicios de infraestructura: posibilidad de desplegar de una forma sencilla máquinas
virtuales con Windows Server o con distribuciones de Linux.
 Controlador de tejido: Windows Azure se ejecuta en un gran número de máquinas. El
trabajo del controlador de tejido es combinar las máquinas en un solo centro de datos de
Windows Azure formando un conjunto armónico. Los servicios de proceso y
almacenamiento de Windows Azure se implementan encima de toda esta eficacia de
procesamiento.
 Red de entrega de contenido (CDN): el almacenamiento en caché de los datos a los que
se accede frecuentemente cerca de sus usuarios agiliza el acceso a esos datos.
 Connect: organizaciones interactúan con aplicaciones en la nube como si estuvieran
dentro del propio firewall de la organización
 Administración de identidad y acceso: La solución Active Directory permite gestionar
de forma centralizada y sencilla el control de acceso y la identidad. Esta solución es
perfecta para la administración de cuentas y la sincronización con directorios locales.

56
2.8.3. Componentes de la plataforma

 Windows Azure Compute es una plataforma para hospedar y administrar aplicaciones

en los centros de datos de Microsoft. Una aplicación de Windows Azure consta de
uno o varios componentes denominados ‘roles.’ Los roles pueden ser de tres tipos:
rol web, rol de trabajo y rol de máquina virtual (VM)
 Windows Azure Storage tiene servicios de básicos como parte de la cuenta de
almacenamiento de Windows Azure. Los blobs, tablas y colas están accesibles a
aplicaciones o instancias de aplicaciones simultáneamente
 Microsoft SQL Azure es un servicio de base de datos en la nube basado en las
tecnologías de SQL Server. Los servicios de SQL Azure incluyen: Base de datos SQL
Azure, SQL Azure Reporting y SQL Azure Data Sync Aspectos destacados de la base
de datos de SQL Azure
 Content Delivery Network (CDN) de Windows Azure coloca copias de los datos
cerca de donde estos se encuentran. La CDN de Windows Azure entrega actualmente
muchos productos de Microsoft, como Windows Update, vídeos de Zune y Bing
Maps, que los clientes conocen y usan todos los días. Gracias a la incorporación de
la CDN a los servicios de Windows Azure, ahora esta red a gran escala está disponible
a todos los usuarios de Windows Azure
 Azure AppFabric El servicio de Appfabric (en fase beta se llamaba .NET Services)
ofrece diferentes servicios para aplicaciones. Los servicios de autenticación,
autorización y mensajería permiten la comunicación segura entre aplicaciones y
servicios desplegados tanto en la nube y en local. Los diferentes servicios que ofrece
el servicio de AppFabric se pueden dividir en dos grandes bloques: AppFabric
Service Bus y AppFabric Access Control

57
Figura 2.3 Windows Azure Fabric, los cimientos sobre los que se levanta la plataforma
Azure.

 Azure Market Place es un mercado en línea global compartir, comprar y vender

aplicaciones SaaS completas y conjuntos de datos. La sección de datos de Windows
Azure Marketplace incluye datos, imágenes y servicios Web en tiempo real de
proveedores de datos comerciales, líderes en el sector y orígenes de datos públicos
acreditados
 Azure Virtual Network es una serie de funciones de red. Windows Azure Connect es
la primera característica de Azure Virtual Network que configura la conectividad de
red basada en IP entre recursos locales y de Windows Azure. Windows Azure Traffic
Manager equilibra la carga del tráfico en servicios hospedados
2.8.4. Beneficios de Windows Azure
 Ejecutar procesos genéricos en la nube

58
 Crear, modificar y distribuir aplicaciones escalables con un mínimo de recursos
internos
 Realizar almacenamiento de alto volumen, procesamiento de lotes y cómputos
intensos o de alto volumen
 Crear, evaluar, depurar y distribuir servicios web con rapidez y de forma accesible
 Llevar sus ideas al mercado con mayor rapidez y paga cuando lo obtiene
 Reduce costes de generación y extensión de recursos internos
 Reduce el esfuerzo y los costes de administración de TI Responde con rapidez a los
cambios de las necesidades de su empresa y sus clientes
 Amplía y reduce sus recursos de TI en función de sus necesidades
 Consume recursos de informática SOLO cuando surgen la necesidad
 Se enfoca menos en administrar restricciones y recursos operativos
 Elimina la necesidad de administrar hardware
 Utiliza sus actuales habilidades de desarrollo para crear aplicaciones en la nube

59
Capitulo 3: - Comparación de Bases de datos Relacionales contra Bases de
datos No Relacionales y sus gestores de bases de datos
3.1. SQL Server

Microsoft SQL Server es un sistema de manejo de bases de datos del modelo relacional,
desarrollado por la empresa Microsoft.

El lenguaje de desarrollo utilizado (por línea de comandos o mediante la interfaz gráfica de

Management Studio) es Transact-SQL (TSQL), una implementación del estándar ANSI del
lenguaje SQL, utilizado para manipular y recuperar datos (DML), crear tablas y definir
relaciones entre ellas (DDL).

Dentro de los competidores más destacados de SQL Server

están: Oracle, MariaDB, MySQL, PostgreSQL. SQL Server solo está disponible
para sistemas operativos Windows de Microsoft.

Puede ser configurado para utilizar varias instancias en el mismo servidor físico, la primera
instalación lleva generalmente el nombre del servidor, y las siguientes - nombres específicos
(con un guion invertido entre el nombre del servidor y el nombre de la instalación).

3.1.1. Caracteristicas
Algunas de las caracteristicas mas importantes de SQL Server son:

 Soporte de transacciones.
 Soporta procedimientos almacenados.
 Incluye también un entorno gráfico de administración, que permite el uso
de comandos DDL y DMLgráficamente.
 Permite trabajar en modo cliente-servidor, donde la información y datos se alojan en
el servidor y losterminales o clientes de la red sólo acceden a la información.
 Además permite administrar información de otros servidores de datos.

Este sistema incluye una versión reducida, llamada MSDE con el mismo motor de base de
datos pero orientado a proyectos más pequeños, que en sus versiones 2005 y 2008 pasa a ser
el SQL Express Edition, que se distribuye en forma gratuita.

60
Es común desarrollar proyectos completos empleando Microsoft SQL Server y Microsoft
Access a través de los llamados ADP (Access Data Project). De esta forma se completa
la base de datos (Microsoft SQL Server), con el entorno de desarrollo (VBA Access), a través
de la implementación de aplicaciones de dos capas mediante el uso de formularios Windows.

En el manejo de SQL mediante líneas de comando se utiliza el SQLCMD, osql, o

PowerShell.

Para el desarrollo de aplicaciones más complejas (tres o más capas), Microsoft SQL
Server incluye interfaces de acceso para varias plataformas de desarrollo, entre ellas .NET,
pero el servidor sólo está disponible para Sistemas Operativos.

El tipo NUMERIC fue mejorado para ser usado como identificador de columna a partir de la
versión 2008 R2.

3.1.2. Versiones
El código fuente original de SQL Server que fue utilizado en las versiones previas a la
versión 7.0 habría sido comprado de Sybase, pero fue actualizado en las versiones 7.0 y 2000,
y reescrito en la versión 2005. Generalmente, cada 2-3 años, una nueva versión es lanzada y,
entre estos lanzamientos, se proponenservice packes con mejoras y correcciones de bugs,
y hotfixes por problemas urgentes en el sistema de seguridad o bugs críticos.

Versión Año Nombre de la versión Nombre clave

1.0 1989 SQL Server 1-0 SQL

(OS/2)

4.21 1993 SQL Server 4.2.1 SEQUEL

(WinNT)

6.0 1995 SQL Server 6.0 SQL95

61
 6.5 1996 SQL Server 6.5 Hydra

7.0 1998 SQL Server 7.0 Sphinx

- 1999 SQL Server 7.0 Plato

OLAP Tools

8.0 2000 SQL Server 2000

8.0 2003 SQL Server 2000 Liberty

64-bit Edition

9.0 2005 SQL Server 2005 Yukon

10.0 2008 SQL Server 2008 Katmai

10.25 2010 SQL Azure DB CloudDatabase

10.50 2010 SQL Server 2008 R2 Kilimanjaro

11.0 2012 SQL Server 2012 Denali

12.0 2014 SQL Server 2014 SQL14 (antes Hekaton)

Tabla 3.1 Historial de versiones de SQL Server

3.1.3. Programación
3.1.3.1. T-SQL
T-SQL (Transact-SQL) es el principal medio de interacción con el Servidor, el cual permite
realizar las operaciones claves en SQL Server, incluyendo la creación y modificación de

62
esquemas de base de datos, inserción y modificación de datos en la base de datos, así como
la administración del servidor como tal. Esto se realiza mediante el envío de sentencias en T-
SQL y declaraciones que son procesadas por el servidor y los resultados (o errores) regresan
a la aplicación cliente.

3.1.3.2. Cliente Nativo de SQL

Cliente Nativo de SQL, es la biblioteca de acceso a datos para los clientes de Microsoft SQL
Server versión 2005 en adelante. Implementa de forma nativa soporte para las características
de SQL Server, incluyendo la ejecución de la secuencia de datos tabular, soporte para bases
de datos en espejo de SQL Server, soporte completo para todos los tipos de datos compatibles
con SQL Server, conjuntos de operaciones asíncronas, las notificaciones de consulta, soporte
para cifrado, así como recibir varios conjuntos de resultados en una sola sesión de base de
datos. Cliente Nativo de SQL se utiliza como extensión de SQL Server plug-ins para otras
tecnologías de acceso de datos, incluyendo ADO u OLE DB. Cliente Nativo de SQL puede
también usarse directamente, pasando por alto las capas de acceso de datos.

3.1.4. Interfaz de usuario

SQL Server proporciona unos interfaz que han cambiado durante los años, de los cuales los
más conocidos son los interfaz gráficos que están utilizados como herramienta de desarrollo
estándar a los desarrolladores y administradores.

La interfaz gráfica hasta 2005 incluyó el Enterprise Manager con una vista de árbol de los
distintos objetos y con la capacidad de manejarlos; y el Query analyzer como interfaz textual
para ejecutar comandos de TSQL.

En la versión 2005 las dos herramientas se unificaron a una –el SQL Server Management
Studio (SSMS), y a partir de 2008 fue incluida la opción de trabajar con el Visual Studio– la
interfaz estándar de desarrollo de Microsoft (a los distintos lenguajes, BI, etc.). Otro interfaz
opcional es la utilización de Línea de comandos, con herramientas como SQLCmd, ISQL,
OSQL que posibilita la ejecución de scripts y procesamiento por lotes. Desde 2008 se puede
desarrollar con SQLCmd (SQL Command) a través del SSMS sin interconectarse al interfaz
textual de Windows. Otra opción en el ámbito de scripts es la utilización del lenguaje de
scripts Powershell de Microsoft.

63
Aparte de los intefazes estándares de SQL Server, se puede ejecutar comandos de TSQL con
herramientas de conexión como ODBC y OLE-DB.

3.1.5. Servicios
A contrario de sistemas de bases de datos como Microsoft Access que son "pasivas" y
contienen un archivo a cual hay que conectar y la ejecución de los comandos se lleva a cabo
en el cliente (la computadora de usuario), en SQL Server hay número de servicios, software
que están ejecutadas en la memoria del servidor por parte del sistema, y por lo tanto
aprovechan las capacidades del servidor que es más potente que los clientes, previenen
congestión en la red, y pueden programar tareas que corran aún el cliente no está conectado.

Los servicios principales:

 SQL Server - El "motor" del sistema

 SQL Agent - Ejecución de tareas (Jobs, scripts programados) y envió de advertencias en
caso de carga pesada e irregulares en el sistema
 Full-Text Filter Daemon Launcher - La utilización en los indexes especiales del "Full
text search" por búsqueda textual avanzada
 SQL Browser - El "oyente" dedicado a comandos enviados y redirigirlos a su destino
 SSIS Server - La operación del SSIS (la herramienta de ETL)
 SSAS Server - La operación del SSAS (la herramienta de OLAP)
 SSRS Server - La operación del SSRS (la herramienta de informes)
3.1.6. Capacidades y herramientas basicas
3.1.6.1. Bases de datos
En cada instalación de SQL Server hay 4 bases de datos de sistema, y la capacidad de crear
nuevas bases de datos por el usuario, en los cuales los datos están almacenados en tablas.

Estas bases de datos, creadas por parte de los usuarios, incluyen básicamente un archivo de
datos (con el sufijo mdf) con las tablas y los distintos objetos a nivel de la base de datos; y
un archivo de registro (con el sufijo ldf) con las transacciones abiertas, y transacciones
cerradas, Sujeto al modelo de recuperación seleccionado (se puede acumular en el archivo
de registro todos los cambios en la base de datos desde el último respaldo). Se puede crear
un conjunto de archivos de datos además del principal (con el sufijo ndf) por consideraciones
de eficiencia, partición de carga de trabajo entre los discos rígidos, etc.

64
Las bases de datos del sistema:

 master - Todos los procedimientos, funciones y tablas del sistema que están utilizadas
por parte de todas las bases de datos y que están instaladas automáticamente, tanto
como las que han sido creado por parte de los administradores del sistema. Además,
todas las definiciones en respecto a la seguridad a nivel del servidor, están
almacenadas en esta base de datos.
 msdb - Almacenamiento de las tareas del agente, los códigos de CLR combinados en
el sistema, los paquetes de SSIS, y otros más.
 model - El molde de las bases de datos. Cada nueva base de datos se crea como una
copia de esta base de datos, menos que algo más estaba definido explícitamente.
 tempdb - Base de datos temporal que se crea de nuevo cada vez que el servicio
reinicia. Se utiliza para almacenar tablas temporales creadas por parte de los usuarios
o el sistema (por ejemplo en ordenaciones complejos).

3.1.6.2. Tablas fijas y temporales

Desde la perspectiva lógica, los datos almacenados en las bases de datos en tablas, que
mediante ellas se implementa la teoría de las bases de datos relacionales. La tabla se divide
en filas y columnas (A veces se les conoce como registros y campos). Las tablas pueden ser
fijas o temporales, mientras que en el segundo caso existen físicamente en la base de datos
tempdb, y se borran automáticamente en caso de desconexión de la sesión o de la conexión
al servidor, depende en el tipo de la tabla temporal.

Desde la perspectiva física, el sistema divide los archivos de la base datos en Extents de
64 KB, y cada cual a ocho páginas de 8 KB. Generalmente, cada Extent se asigna a una tabla
o un índice, menos las tablas pequeñas; y cada página se asigna siempre a una tabla
específica. El sistema es responsable del aumento de los archivos, de acuerdo con los ajustes
del usuario, y de asignar Extents y páginas a las tablas.

A las tablas se puede crear índices. Los índices se almacenan junto a la tabla (Non Clustered
Index) o son la tabla en sí (Clustered Index). Los índices asisten en la búsqueda de datos en
las tablas (como los ficheros en las librerías), en ordenarlas, y la definición de claves
primarias.

Entre las tablas se puede crear una relación de uno a muchos.

65
Aparte de las tablas de los usuarios, hay tablas que almacenan meta data: datos sobre el
sistema mismo, los diferentes objetos, los derechos, estadísticas sobre el rendimiento del
sistema (DMV), etc.

3.1.6.3. Tipos de datos

Para cada columna en una tabla y a cada variable o parámetro, se define un tipo de datos que
sean almacenados en él, entre ellos:

 Numeros: Números enteros y no enteros en distintos tamaños, y en diferentes niveles

de precisión; y auto incremento opcional.
 Textos: Cadenas de distintas longitudes, y distintas capacidades de apoyar distintas
lenguas.
 Fechas: Fechas en distintos niveles de precisión, desde días completos hasta
fracciones menores de un segundo, que apoyan fechas a partir del principio del siglo
20 o del calendario gregoriano, y la capacidad de diferenciar entre distintos usos de
horarios.
 XML: Datos textuales (cadenas) que representan conjuntos estándares de datos
(estándar SGML).
 Datos binarios: Datos almacenados como datos binarios (bits y bytes), que posibilitan
el almacenamiento de archivos gráficos, etc.
 Geography: Representación estándar de información geográfica, tales como estados,
zonas geográficas, localidades; y las cálculos como distancias.
 Geometry: Representación estándar de puntas, líneas, superficies en el plano; y las
relaciones entre ellas.
 Hierarchid: Representación estándar de información jerárquica como lista de
materiales, relaciones de subordinación entre empleados, etc.

3.1.6.4. Vistas
Las vistas representan generalmente comandos de extracción de datos, que se almacenan sin
los datos (que están almacenados en las tablas). Esta opción nos posibilita crear extracciones
complejas o estándares, almacenarlas como vistas, y utilizar las vistas sin la necesidad de
escribir de nuevo los comandos o mantener los códigos donde ellas aparecen.
Adicionalmente, es un medio muy importante para otorgar derechos selectivos de lectura (en

66
caso que queremos posibilitar a un usuario contemplar parcialmente las columnas o las filas
de una tabla).

Una vista se puede considerar una tabla virtual o una consulta almacenada. Los datos
accesibles a través de una vista no están almacenados en un objeto distinto de la base de
datos. Lo que está almacenado en la base de datos es una instrucción SELECT. El resultado
de la instrucción SELECT forma la tabla virtual que la vista devuelve. El usuario puede
utilizar dicha tabla virtual haciendo referencia al nombre de la vista en instrucciones
Transact-SQL, de la misma forma en que se hace referencia a las tablas. Las vistas se utilizan
para alguna de estas funciones, o para todas:

 Restringir el acceso del usuario a filas concretas de una tabla. Por ejemplo,
permitir que un empleado sólo vea las filas que guardan su trabajo en una
tabla de seguimiento de actividad laboral.
 Restringir el acceso del usuario a columnas específicas. Por ejemplo, permitir
que los empleados que no trabajen en el departamento de nóminas vean las
columnas de nombre, oficina, teléfono y departamento de la tabla de
empleados, pero no permitir que vean las columnas con los datos de salario u
otra información personal.
 Combinar columnas de varias tablas de forma que parezcan una sola tabla.
 Agregar información en lugar de presentar los detalles. Por ejemplo, presentar
la suma de una columna o el valor máximo o mínimo de una columna.

Las vistas se crean definiendo la instrucción SELECT que recupera los datos presentados por
la vista. Las tablas de datos a las que hace referencia la instrucción SELECT se conocen
como las tablas base para la vista. Las vistas en todas las versiones de SQL Server son
actualizables (pueden ser objetivo de instrucciones UPDATE, DELETE o INSERT) mientras
la modificación afecte sólo a una de las tablas base de la vista.

3.1.6.5. Procedimientos almacenados

Los procedimientos son scripts de comandos de TSQL, que pueden ser ejecutados con
distintos parámetros. Por ejemplo, procedimiento que obtiene número de año como
parámetro, y actualiza una tabla de resumen de ventas, con las ventas de los agentes en el
dicho año, basada en la tabla de registro de ventas.

67
Los procedimientos almacenados pueden facilitar en gran medida la administración de la
base de datos y la visualización de información sobre dicha base de datos y sus usuarios. Los
procedimientos almacenados son una colección precompilada de instrucciones SQL e
instrucciones de control de flujo opcionales almacenadas bajo un solo nombre y procesadas
como una unidad. Los procedimientos almacenados se guardan en una base de datos; se
pueden ejecutar desde una aplicación y permiten variables declaradas por el usuario,
ejecución condicional y otras funciones eficaces de programación. Los procedimientos
almacenados pueden contener flujo de programas, lógica y consultas a la base de datos.
Pueden aceptar parámetros, proporcionar resultados de parámetros, devolver conjuntos de
resultados individuales o múltiples y devolver valores.

Las ventajas de utilizar procedimientos almacenados en SQL Server en vez de programas

Transact-SQL almacenados localmente en equipos clientes consisten en que:

 Permiten una programación modular. Puede crear el procedimiento una vez,

almacenarlo en la base de datos, y llamarlo desde el programa el número de veces
que desee. Un especialista en programación de bases de datos puede crear
procedimientos almacenados, que luego será posible modificar independientemente
del código fuente del programa. Facilitan el mantenimiento.
 Permiten una ejecución más rápida. En situaciones en las que se necesita una gran
cantidad de código Transact-SQL, o si las operaciones se realizan varias veces, los
procedimientos almacenados pueden ser más rápidos que los lotes de código
Transact-SQL. Los procedimientos son analizados y optimizados en el momento de
su creación, y es posible utilizar una versión del procedimiento que se encuentra en
la memoria después de que se ejecute por primera vez. Las instrucciones de Transact-
SQL que se envían varias veces desde el cliente cada vez que deben ejecutarse tienen
que ser compiladas y optimizadas siempre que SQL Server las ejecuta.
 Pueden reducir el tráfico de red. Una operación que necesite centenares de líneas de
código Transact-SQL puede realizarse mediante una sola instrucción que ejecute el
código en un procedimiento, en vez de enviar cientos de líneas de código por la red.

68
  Pueden utilizarse como mecanismo de seguridad. Es posible conceder permisos a los
usuarios para ejecutar un procedimiento almacenado, incluso si no cuentan con
permiso para ejecutar directamente las instrucciones del procedimiento.

3.1.7. Funciones definidas por el usuario

Las funciones son un objeto que combina algunas capacidades de las vistas, con otras de los
procedimientos. Como las vistas, pueden extraer datos y ejecutar cálculos, y devuelven un
resultado al usuario o al programa que les ejecuto. Tanto como los procedimientos, incluyen
códigos de TSQL, y pueden ser ejecutados con parámetros.

Las funciones devuelven un valor o un conjunto de valores.

Las funciones definidas por el usuario se crean con la instrucción CREATE FUNCTION, se
modifican con la instrucción ALTER FUNCTION y se quitan con la instrucción DROP
FUNCTION. Todos los nombres de funciones completos
(database_name.owner_name.function_name) definidos por el usuario deben ser únicos.
Para crear, modificar o quitar funciones definidas por el usuario, debe tener permisos de
CREATE FUNCTION. Los usuarios distintos del propietario deben tener permiso
EXECUTE para una función, y solo así podrán utilizarla en una instrucción de Transact-
SQL. Para crear o modificar tablas con referencias a funciones definidas por el usuario en la
restricción CHECK, la cláusula DEFAULT o la definición de una columna calculada,
también debe tener permiso REFERENCES para las funciones. Los errores de Transact-SQL
que producen la cancelación de una instrucción y continúan con la siguiente instrucción del
módulo, como desencadenadores o procedimientos almacenados, se tratan de forma distinta
dentro de una función. En las funciones, estos errores hacen que se detenga la ejecución de
la función. Esto hace que se cancele la función que invocó la instrucción. Una función
definida por el usuario no tiene ninguno o tiene varios parámetros de entrada y devuelve un
valor escalar o una tabla. Una función puede tener un máximo de 1024 parámetros de entrada.
Cuando un parámetro de la función toma un valor predeterminado, debe especificarse la
palabra clave DEFAULT al llamar a la función para poder obtener el valor predeterminado.
Este comportamiento es diferente del de los parámetros con valores predeterminados de los
procedimientos almacenados, para los cuales omitir el parámetro implica especificar el valor
predeterminado. Las funciones definidas por el usuario no admiten parámetros de salida.

69
 3.1.8. Consultas Distribuidas
Las consultas distribuidas tienen acceso a datos de varios orígenes, que pueden estar
almacenados en un equipo o en equipos distintos. Microsoft SQL Server 2000 admite las
consultas distribuidas a través de OLE DB Las consultas distribuidas proporcionan a los
usuarios de SQL Server acceso a:

 Datos distribuidos almacenados en múltiples instancias SQL Server.

 Datos heterogéneos almacenados en varios orígenes de datos relacionales y no
relacionales a los que se tiene acceso mediante un proveedor OLE DB.

Los proveedores OLE DB exponen datos en objetos tabulares llamados conjuntos de filas.
En las instrucciones Transact-SQL, SQL Server 2000 permite que se haga referencia a los
conjuntos de filas de los proveedores OLE DB como si fueran una tabla de SQL Server.

En las instrucciones SELECT, INSERT, UPDATE y DELETE de Transact-SQL, se puede

hacer referencia directa a las tablas y vistas de orígenes de datos externos. Puesto que las
consultas distribuidas usan OLE DB como interfaz subyacente, éstas tienen acceso a los
sistemas DBMS relacionales tradicionales con procesadores de consultas SQL, así como a
los datos administrados por orígenes de datos de capacidad y sofisticación diversas.

Siempre que el software propietario de los datos los expone en un conjunto de filas tabular a
través del proveedor OLE DB, los datos se podrán usar en las consultas distribuidas. Nota:
El uso de las consultas distribuidas en SQL Server es similar a la funcionalidad de las tablas
vinculadas mediante ODBC, que anteriormente admitía Microsoft Access. Esta
funcionalidad se encuentra ahora integrada en SQL Server con OLE DB como interfaz para
los datos externos.

3.1.9. El optimizador
El optimizador es una parte del software que "toma la decisión" de como cada comando se
ejecutará, tanto que la ejecución será lo más eficiente, o por lo menos bastante eficiente (es
decir, bastante eficiente para evitar seguir buscando otra solución, que aún que sea más
eficiente, el precio de la búsqueda adicional "costará" más que el ahorro de recursos).

SQL es un lenguaje declarativo, en el cual el desarrollador declara que quiere extraer o

actualizar sin la necesidad de indicar cómo (a contrario de los lenguajes imperativos, y por

70
lo tanto el optimizador juega un papel protagónico, que de acuerdo con las estadísticas que
el sistema almacena sobre las distribuciones de los datos en las tablas, los indexes, y reglas
internas; toma la decisión adecuada.

3.2.MongoDB

MongoDB (de la palabra en inglés “humongous” que significa enorme) es un sistema de base
de datos NoSQL orientado a documentos, desarrollado bajo el concepto de código abierto.

MongoDB forma parte de la nueva familia de sistemas de base de datos NoSQL. En lugar de
guardar los datos en tablas como se hace en las base de datos relacionales, MongoDB guarda
estructuras de datos en documentos similares a JSON con un esquema dinámico (MongoDB
utiliza una especificación llamada BSON), haciendo que la integración de los datos en ciertas
aplicaciones sea más fácil y rápida

3.2.1. Caracteristicas
Lo siguiente es una breve descripción de las características principales de MongoDB:

3.2.1.1.Consultas Ad Hoc
MongoDB soporta la búsqueda por campos, consultas de rangos y expresiones regulares. Las
consultas pueden devolver un campo específico del documento pero también puede ser una
funciónJavaScript definida por el usuario.

3.2.1.2.Indexación
Cualquier campo en un documento de MongoDB puede ser indexado, al igual que es posible
hacer índices secundarios. El concepto de índices en MongoDB es similar a los encontrados
en base de datos relacionales.

3.2.1.3.Replicación
MongoDB soporta el tipo de replicación primario-secundario. Cada grupo de primario y sus
secundarios se denomina replica set . El primario puede ejecutar comandos de lectura y
escritura. Los secundarios replican los datos del primario y sólo se pueden usar para lectura
o para copia de seguridad, pero no se pueden realizar escrituras. Los secundarios tiene la
habilidad de poder elegir un nuevo primario en caso de que el primario actual deje de
responder.

71
 3.2.1.4.Balanceo de carga
MongoDB se puede escalar de forma horizontal usando el concepto de “shard”. El
desarrollador elige una clave de sharding, la cual determina cómo serán distribuidos los datos
de una colección. Los datos son divididos en rangos (basado en la clave de sharding) y
distribuidos a través de múltiples shard. Cada shard puede ser una replica set. MongoDB
tiene la capacidad de ejecutarse en múltiple servidores, balanceando la carga y/o replicando
los datos para poder mantener el sistema funcionando en caso que exista un fallo de hardware.
La configuración automática es fácil de implementar bajo MongoDB y se pueden agregar
nuevas servidores a MongoDB con el sistema de base de datos funcionando.

3.2.1.5.Almacenamiento de archivos
MongoDB puede ser utilizado como un sistema de archivos, tomando la ventaja de la
capacidad que tiene MongoDB para el balanceo de carga y la replicación de datos utilizando
múltiples servidores para el almacenamiento de archivos. Esta función se llama GridFS y es
mas bien una implementación en los drivers, no en el servidor, por lo que está incluida en los
drivers oficiales que la compañía de MongoDB desarrolla. Estos drivers exponen funciones
y métodos para la manipulación de archivos y contenido a los desarrolladores. En un sistema
con múltiple servidores, los archivos pueden ser distribuidos y replicados entre los mismos
y de una forma transparente, de esta forma se crea un sistema eficiente que maneja fallos y
balanceo de carga.

3.2.1.6.Agregación
MongoDB proporciona un framework de agregación que permite realizar operaciones
similares a las que se obtienen con el comando SQL "GROUP BY". El framework de
agregación está construido como un pipeline en el que los datos van pasando a través de
diferentes etapas en los cuales estos datos son modificados, agregados, filtrados y
formateados hasta obtener el resultado deseado. Todo este procesado es capaz de utilizar
índices si existieran y se produce en memoria. Asimismo, MongoDB proporciona una
función MapReduce que puede ser utilizada para el procesamiento por lotes de datos y
operaciones de agregación.

3.2.1.7.Ejecución de JavaScript del lado del servidor

MongoDB tiene la capacidad de realizar consultas utilizando JavaScript, haciendo que estas
sean enviadas directamente a la base de datos para ser ejecutadas.

72
 3.2.2. Como funciona MongoDB
MongoDB está escrito en C++, aunque las consultas se hacen pasando objetos JSON como
parámetro. Es algo bastante lógico, dado que los propios documentos se almacenan en
BSON. Por ejemplo:

db.Clientes.find({Nombre:"Pedro"});

La consulta anterior buscará todos los clientes cuyo nombre sea Pedro.

MongoDB viene de serie con una consola desde la que podemos ejecutar los distintos
comandos. Esta consola está construida sobre JavaScript, por lo que las consultas se realizan
utilizando ese lenguaje. Además de las funciones de MongoDB, podemos utilizar muchas de
las funciones propias de JavaSciprt. En la consola también podemos definir variables,
funciones o utilizar bucles.

Si queremos usar nuestro lenguaje de programación favorito, existen drivers para un gran
número de ellos. Hay drivers oficiales para C#, Java, Node.js, PHP, Python, Ruby, C, C++,
Perl o Scala. Aunque estos drivers están soportados por MongoDB, no todos están en el
mismo estado de madurez. Por ejemplo el de C es una versión alpha. Si queremos utilizar un
lenguaje concreto, es mejor revisar los drivers disponibles para comprobar si son adecuados
para un entorno de producción.

3.2.3. Casos de uso

La base de datos MongoDB es adecuada para los siguientes usos:

 Almacenamiento y registro de eventos

 Para sistemas de manejo de documentos y contenido
 Comercio Electrónico
 Juegos
 Problemas de alto volumen de lecturas
 Aplicaciones móviles
 Almacén de datos operacional de una página web
 Manejo de contenido
 Almacenamiento de comentarios

73
  Votaciones
 Registro de usuarios
 Perfiles de usuarios
 Sesiones de datos
 etc.

 Proyectos que utilizan metodologías de desarrollo iterativo o ágiles

 Manejo de estadísticas en tiempo real

MongoDB es utilizado para uno o varios de estos casos por varias empresas.

Aunque se suele decir que las bases de datos NoSQL tienen un ámbito de aplicación reducido,
MongoDB se puede utilizar en muchos de los proyectos que desarrollamos en la actualidad.

Cualquier aplicación que necesite almacenar datos semi estructurados puede usar MongoDB.
Es el caso de las típicas aplicaciones CRUD o de muchos de los desarrollos web actuales.

Eso sí, aunque las colecciones de MongoDB no necesitan definir une esquema, es importante
que diseñemos nuestra aplicación para seguir uno. Tendremos que pensar si necesitamos
normalizar los datos, denormalizarlos o utilizar una aproximación híbrida. Estas decisiones
pueden afectar al rendimiento de nuestra aplicación. En definitiva el esquema lo definen las
consultas que vayamos a realizar con más frecuencia.

MongoDB es especialmente útil en entornos que requieran escalabilidad. Con sus opciones
de replicación y sharding, que son muy sencillas de configurar, podemos conseguir un
sistema que escale horizontalmente sin demasiados problemas.

3.2.4. ¿Dónde no se debe usar MongoDB?

En esta base de datos no existen las transacciones. Aunque nuestra aplicación puede utilizar
alguna técnica para simular las transacciones, MongoDB no tiene esta capacidad. Solo
garantiza operaciones atómicas a nivel de documento. Si las transacciones son algo
indispensable en nuestro desarrollo, deberemos pensar en otro sistema.

Tampoco existen los JOINS. Para consultar datos relacionados en dos o más colecciones,
tenemos que hacer más de una consulta. En general, si nuestros datos pueden ser

74
estructurados en tablas, y necesitamos las relaciones, es mejor que optemos por un RDBMS
clásico.

Y para finalizar, están las consultas de agregación. MongoDB tiene un framework para
realizar consultas de este tipo llamado Aggregation Framework. También puede usar Map
Reduce. Aún así, estos métodos no llegan a la potencia de un sistema relacional. Si vamos a
necesitar explotar informes complejos, deberemos pensar en utilizar otro sistema. Eso sí, esta
es una brecha que MongoDB va recortando con cada versión. En poco tiempo esto podría
dejar de ser un problema.

3.3.Comparación entre bases de datos relacionales y bases de datos no relacionales

Representaremos las comparaciones entre las bases de datos relacionales y no relacionales
en la siguiente tabla:

Bases de datos relacionales Bases de datos No

Relacionales
Estructura de datos Asume una estructura de Posee una estructura
datos definida definida que flexible, no es necesario
tienda a ser uniforme y las definir uan estructura de
propiedades de los datos datos.
pueden definirse de
antemano
Relaciones entre tablas Estan bien establecidas y No existe relación entre
deben ser referenciadas de colección, no obstante
forma sistematica puede depender del modelo
de los datos.
Transaccionalidad Utiliza ACID (Atomicidad, Se pierde integridad en las
consistencia, aislamiento, transacciones
durabilidad)

75
 Consultas e indices Disminuye el uso de
indexación y el poder de las
consultas
Tabla 3.2 Comparación entre bases de datos relacionales y no relacionales

Mostraremos las diferencias entre las bases de datos relacionales y no relacionales en la

siguiente tabla.

Bases de datos relacionales Bases de datos No

Relacionales
Escalabilidad Baja Alta
Rendimiento Bajo Alto
Fiabilidad Alta Baja
Propiedades Utiliza propiedades ACID Utiliza propiedades BASE
Licenciamiento Costoso Mayoría de gestores noSQL
son de software libre
Seguridad Alta Muy baja
Procesamiento de datos Lento Veloz
Tabla 3.3 Diferencias entre las baes de datos relacionales y no relacionales

Si bien NoSql, no pretende erradicar ni suplantar al SQL y a las bases de datos relacionales,
sino pretende ser una alternativa dentro del desarrollo del software donde las condiciones
sean requeridas principalmente cuando se manejan millones y millones de datos y el
procesamiento y escalabilidad sean puntos críticos, Sin embargo Las Comunidades NoSQL
anuncian que no tienes que ser Google para usarlo.

Aunque sabemos que las bases de datos son sistemas de almacenamiento de información,
estas también cuentan con un límite de registros o datos máximo, no porque ya no se puedan
almacenar registros sino porque empiezan a crecer los tiempos de espera considerablemente.
Las NoSQL son DB que sacrifican orden por manejar un número mayor de datos las cuales
llegan hasta en Terabytes.

3.3.1. ¿Cuándo utilizar SQL?

Una base de datos relacional puede ser usada estos ámbitos:

76
  Educativo: es importante conocer cómo estructurar información, además de aportar
un gran conocimiento lógico al estudiante.
 Desarrollo web: es bueno tratar de mantener una misma jerarquía de los datos que
llegan de la gran autopista, pero siempre y cuando la capacidad de concurrencia,
almacenamiento y mantenimiento no sean de considerable dificultad y la información
siempre sea consistente.
 Rama de negocios: inteligencia de negocios, análisis de negocios, bodegas de datos,
minería de datos, minería de texto son temas que requieren el uso de SQL para
facilitar el consumo de la información y la identificación de patrones en los datos.
 Empresarial: El software a la medida y el software empresarial, ambos de escritorio,
poseen la característica de mantener información con una estructura consistente y
SQL es ideal para ésta tarea.

3.3.2. ¿Cuándo utilizar NoSQL?

Las tecnologías NoSQL pueden user usadas en los siguientes ámbitos:

 Redes sociales: Es obligatorio. Gracias a las redes sociales, ésta tecnología comenzó
a despegar y mostrar utilidad en el campo de la informática y la estadística.
 Desarrollo Web: Considero más pertinente el uso de éstas tecnologías en ésta área,
debido a la poca uniformidad de la información que encontramos en Internet, sin
embargo, es posible realizar éstos desarrollos con SQL, como expuse anteriormente.
 Desarrollo Móvil: En éstos momentos, las empresas están lidiando con un problema
grande conocido como Bring Your Own Device – en realidad no es un problema, es
un fenómeno social -, por lo que la información que se recolecte siempre será
diferente por más que uno desee estructurarla y mantenerla estática.
 BigData: Como podemos observar en Search Business Analytics, la administración
de grandísimas cantidades de información y su evidente heterogeneida hace de
NoSQL un excelente candidato en ésta área.
 Cloud (XaaS): el término XaaS (Everything as a service) que indica “Cualquier cosa
como servicio (sic)” y todos los temas relacionados a la nube, con NoSQL pueden
adaptarse casi a cualquier necesidad del cliente, que evidentemente son heterogéneos.

77
Capitulo 4: Pruebas de desempeño de los ambientes
4.1.Motivación y metodología de las pruebas
Las pruebas a exponer en este capitulo las podemos dividir en dos tipos: pruebas de inserción,
tambien conocidas como pruebas de escritura, y pruebas de consulta y lectura.

El objetivo de las pruebas de inserción es: poder calcular el tiempo aproximado que tarda
cada uno de los ambientes virtuales en completar una serie de instrucciones de modo que se
pueda comparar el desempeño a razon de tiempo de cada iteración.

El objetivo de las pruebas de consulta y lectura es: medir la cantidad de tiempo que tardan
los ambientes virtuales en realizar consultas escalares y lecturas a la base de datos con
diferentes cantidades de iteraciones.

4.2.Caracteristicas de las de prueba

Las pruebas tienen objetivos diferentes y por tal motivo tienen caracteristicas diferentes, que
se definen a continuación:

 Caracteristicas de las pruebas de inserción: consisten en mediciones de tiempo en

donde ingresaremos los datos de manera secuencial mediante iteraciones e ir
midiendo cuanto tarda en realizar el proceso completo de inserción en los ambientes
de prueba. Se realizaran 6 iteraciones en las cuales estaremos ingresando 100, 1000,
5000, 25000, 100000 y 500000 registros de datos.
 Caracteristicas de las pruebas de consultas y lectura: busca medir el comportamiento
de los ambiente realizando diferentes consultas como lo son:
 Consultas escalares aleatorias: realizando 100 consultas escalares contra
registros aleatorios en un bucle meidante la generación de numeros aleatorios
que se correlacionan con valores de columnas de identificador de la base de
datos.
 Consultas de campos multiples: recuperando información de la tabla objetivo
en donde se realizaron consultas logicas.

De igual forma se estara midiendo el nivel de uso del servidor en los siguientes aspectos:

78
  Porcentaje de memoría utilizada: porcentaje de la memoria RAM utilizada para
realizar las operaciones.
 Porcentaje del procesador utilizado: porcentaje del procesador utilizado para realizar
las operaciones.
 Lectura de disco: cantidad de kilobytes por segundo (kb/s) que se leyeron en una
determinada instancia.
 Escritura en disco: cantidad de kilobytes por segundo (kb/s) que ingresaron al disco
por iteración.

4.3.Detalles de las pruebas de desempeño

Para poder entender las pruebas de desempeño, tanto de consulta y lectura como de escritura
o inserción, es necesario detallar el proceso por medio del cual mediremos el tiempo de las
distintas iteraciones y como detallamos las mediciones que nos brinda el servidor.

4.3.1. Medicion del tiempo

Para medir los intervalos de tiempo utilizamos el comando DateTime.Now que nos brinda el
tiempo exacto del inicio de la iteración al tiempo que lo almacenamos en una variable, que
llamaron t0, al final de la iteración volvemos a calcular el proceso con la diferencia que esta
vez realizamos una operación que es:

dt = DateTime.Now – t0;

De esta forma podemos encontrar cuanto tiempo dura una iteración dependiendo de la
cantidad de veces que esta tenga que ser repetida.

79
4.3.2. Medición de variables del servidor
Al referirnos a variables del servidor nos referimos a los datos que nos brinda el portal de
Windows Azure en el cual manejamos las maquinas virtuales tal como se ve en la figura 4.1.

Figura 4.1 – Portal de Windows Azure desde donde se puede ver el centro aplicaciones y ver
las estadisticas que el sistema genera

Estos datos son referentes a:

 Porcentaje de memoría utilizada

 Porcentaje del procesador utilizado
 Lectura de disco
 Escritura en disco

Y son presentados mediante sus valores minimo y maximo alcanzado durante la iteración y
el valor promedio al cual la variable trabajo. Estos datos son de suma importancia porque nos
ayudan a ver como interactua el entorno con las iteraciones que se estan llevando acabo.

80
4.4.Configuración del ambiente virtual
El entorno en el que desarrollaremos el experimiento esta basado en un sistema Cloud en
donde interactuamos directamente con los servidores virtuales. La siguienta tabla 4.1 provee
la información que muestra las caracteristicas de las máquinas virtuales utilizadas en nuestras
pruebas.

Manejador de
Sistema Cantidad Memoría
Bases de Región Memoría
Operativo de núcleos RAM
Datos
Windows 1023 GB
SQL Server East 3.5 GB de
1 Server 2012 2 núcleos de
2014 SPI US 2 memoria
R2 memoría
Mongo 1023 GB
East Ubuntu 3.5 GB de
2 Community 2 núcleos de
US 2 Server 15.10 memoria
Server 3.2.6 memoría
Tabla 4.1 – Caracteristicas de las máquinas virtuales utillizadas para las pruebas

La maquina numero 1 la provisionamos con SQL Server 2014 SPI y para la maquina virtual
numero 2 cargamos Mongo Community Server 3.2.6.

Cabe destacar que las dos máquinas fueron creadas en el segundo DataCenter de Microsoft
del este de los Estados Unidos, tambien conocido como East US 2 ubicado en Virginia, ya
que debido a nuestra posición geografica esta tiene la menor latencia promedio con respecto
al resto de los datacenters.

4.4.1. Base de datos a utilizar

La base de datos que utilizaremos es conocida como Northwind, esta fue creada para ser
utilizada principalmente por SQL Server en sus versiones 2005 y 2008, siendo la ultima
actualización a esta en el 2011.

En la figura 4.1 podemos ver el modelo entidad relación de la base de datos a utilizar.

81
Figura 4.1 – Modelo Entidad Relación de la base de datos

Para hacer uso de ella en nuestros ambientes virtuales tenemos que realizar ciertas
adecuaciónes los cuales son:

4.4.1.1.SQL Server

 En primer lugar debemos ir a la página de codeplex northwind

(http://northwinddatabase.codeplex.com), cuando entremos nos dirigimos al menú
superior que dice Downloads y descargamos el archivo que dice Northwind.sql.zip, una
vez descargado procedemos a descomprimirlo.
 Ahora abrimos el archivo que dice northwind.sql mediante un bloc de notas y sin hacer
ninguna modificación seleccionamos la opción de guardar como… En la venta de guardar
como, iremos hasta la parte inferiro y en la lista desplegable Codificación cambiamos el

82
 tipo a UTF-8 y le damos clic en el boton de guardar. Esta acción cambiara la
configuración del archivo y cambiara su tamaño.
 Abrimos el SQL Server Management Studio y creamos una nueva base de datos llamada
Northwind con los valores que vienen predeterminados.
 Una vez tengamos esto abrimos el archivo northwind.sql desde el SQL Server
Management Studio y ejecutamos el archivo (desde el boton Ejecutar o presionando la
tecla F5). Luego de unos minutos SQL Server Management Studio nos indicara que las
consultas han sido ejectuadas correctamente y ya podremos utilizar la base de datos.

4.4.1.2.MongoDB

Para poder instalar Northwind debemos de realizar los siguietnes pasos:

1. Descargamos la base de datos desde la siguiente página:

https://github.com/tmcnab/northwind-mongo
2. Corremos el siguiente comando en PowerShell para poder importalo:

Get-ChildItem "C:\MongoDb\samples\northwind\csv" -Filter *.csv | `

Foreach-Object {
C:\MongoDb\bin\mongoimport.exe -h localhost:55000 -d northwind -c $_.BaseName
--type csv --file $_.FullName --headerline
}
De esta forma podemos instalar nuestra base de datos para que el gestor pueda reconocerlo.

4.5.Resultado de las pruebas

En esta sección se exponen los resultados de las pruebas, debemos recordar que las pruebas
son pruebas numericas y por lo tanto es necesario explicar sus resultados mediante gráficas
y analisis de datos.

4.5.1. Pruebas de inserción

4.5.1.1.Desarollo
La prueba de inserción de datos consiste en ingresar datos de forma secuencial al tiempo que
se calcula el tiempo que tarda en realizar el ciclo, la memoria que se utiliza, el numero de
escritura en disco, el porcentaje de RAM utilizada y el porcentaje del procesador utilizado.

83
Una vez terminada una iteración incrementamos la cantidad de valores para cada iteración.
Los valores son 100, 1000, 5000, 25000, 100000 y 500000.

En la tabla 4.2 se resume los resultados de tiempo de las pruebas de inserción.

Cantidad de valores SQL (seg) MongoDB (seg)

100 1.42 0.23

1,000 2.66 0.44
5,000 9.67 1.37
25,000 47.24 5.67
100,000 198.43 25.07
500,000 998.72 132.72
Tabla 4.2 – Resultados de tiempo de las pruebas de inserción

En las tablas 4.3 y 4.4 mostramos los resultados para SQL Server y MongoDB
respectivamente, en cuanto a memoria utilizada, el numero de escritura en disco, el
porcentaje de RAM utilizada y el porcentaje del procesador utilizado.

Escrituras en disco Porcentaje del procesador Porcentaje de Memoria

Valores
(kb/s) utilizado RAM utilizada
Minimo 27.85 36.79 40.26
Promedio 41.14 38.93 46.47
Maximo 54.43 41.08 52.62
Tabla 4.3 – Resultados de SQL Server en consumo de recursos del servidor

Escrituras en disco Porcentaje del procesador Porcentaje de Memoria

Valores
(kb/s) utilizado RAM utilizada
Minimo 27.85 32.52 45.76
Promedio 41.14 34.37 50.45
Maximo 54.43 36.23 55.14
Tabla 4.4 – Resultados de MongoDB en consumo de recursos del servidor

84
4.5.1.1.1. Analisis de los resultados de las pruebas
Como podemos ver en la gráfica 4.1 encontramos que la diferencia en el desempeño entre
ambas bases de datos es impresionante siendo MongoDB siete veces mas rápida que SQL
Server al momento de realizar inserciones en la base de datos.

PRUEBA DE ESCRITURA
SQL (seg) MongoDB (seg)

998.72
TIEMPO

198.43

132.72
47.24

25.07
9.67

5.67
2.66
1.42

1.37
0.44
0.23

100 1,000 5,000 25,000 100,000 500,000

CANTIDAD DE VALORES AGREGADOS

Gráfica 4.1

Este tipo de resultados es de esperarse debido a que MongoDB esta fundamentado en NoSQL
de modo que cuando realizamos inserciones en la base de datos esta se almacena como un
objeto para luego agregarle distintos campos que terminan de describir al objeto que
acabamos de agregar. MongoDB de este modo.

MongoDB es superior a SQL Server para las inserciones que requieren un nivel de "mejor
esfuerzo" de la persistencia. MongoDB se basa en la escritura de archivos asignados a la
memoria en el disco y vuelve tan pronto como la memoria se ha actualizado, pero antes de
que el sistema operativo ha terminado de sincronizar el archivo asignado en memoria. SQL
Server por el contrario devuelve resultados sólo después de que los datos se hayan conectado
de forma integra lo cual hace mas lento a SQL Server pero mas fiable.

Viendo de igual forma los valores de las tablas 4.3 y 4.4 son utilizados en la grafica 4.2 que
se presenta a continuación.

85
 Uso de recursos
60

50

40

30

20

10

0
Escrituras en disco (kb/s) Porcentaje del procesador Porcentaje de Memoria RAM
utilizado utilizada

Promedio Promedio

Gráfica 4.2

En esta apreciamos el valor promedio de las inserciones en el disco, el porcentaje del

procesador utilizado y porcentaje de memoria Ram usada. De las cuales podemos determinar
que el numero de escrituras se mantiene ya que en ambas bases de datos estamos agregando
el mismo codigo de valores que se forma y en igual cantidad, en donde podemos ver una
diferencia apreciable es en el procentaje del procesador siendo en MongoDB el gestor que
ahorra un poco en el uso de procesador. En cuanto al porcentaje de memoría RAM
encontramos que MongoDB utiliza más memoría RAM al momento de insertar datos que
SQL Server, esto se debe principalmente al funcionamiento de MongoDB en el cual los datos
ingresados utilizan los recursos disponibles para almacenarse antes de pasarlos al sistema
operativo para que los almacene en la memoria.

Es importante señalar que aunque SQL Server tenga un mayor tiempo de consulta en
comparación contra MongoDB, SQL Server nos ofrece una mejor integridad de los datos.

4.5.2. Pruebas de consulta y lectura

4.5.2.1.Desarrollo
La prueba de consulta y lectura consisten en una serie de pruebas contra los registros de las
bases de datos para comprobar el comportamiento del ambiente virtual y el tiempo en que
tardan en completarse las instrucciones para provisionar los resultados.

86
Realizamos las siguientes pruebas :

 Consultas escalares aleatorias: Se realizaron cien (100) consultas escalares, pruebas de

rango de datos y operaciones aritmeticas, contra registros aleatorios en un bucle mediante
la generación de numeros aleatorios que se correlacionan con valores de las columnas de
identificador de la base de datos.
 Consultas de campos multiples: Se realizaron dos pruebas en un ciclo de 100 iteraciones.
 Recuperando información de la tabla objetivo donde el elemento ‘A’ es mayor ‘x’ y
el elemento ‘B’ es mayor a ‘x’.
 Recuperando un conjunto de resultados de una tabla donde un elemento hijo es
mayor que ‘X’

Las pruebas son realizadas contra las bases de datos de MongoDB y SQL Server son sobre
1000, 10000 y 100000 registros.

Los resultados de las pruebas de lectura fueron radicales a nivel de resultados. La tabla 4.5
muestra la comparación de rendimiento en segundos para SQL Server y MongoDB.

Prueba Numero de registros SQL Server MongoDB

6.47 1.28
Consultas escalares aleatorias 1,000

13.6 4.731
Consultas de campos multiples 1,000

51.29 15.23
Consultas escalares aleatorias 10,000

176.805 54.714
Consultas de campos multiples 10,000

637.24 398.02
Consultas escalares aleatorias 100,000

1102.823 689.83
Consultas de campos multiples 100,000

Tabla 4.5 – Resultados de MongoDB en consumo de recursos del servidor

87
En las tablas 4.6 y 4.7 mostramos los resultados para SQL Server y MongoDB
respectivamente, en cuanto a memoria utilizada, el numero de lectura en disco, el porcentaje
de RAM utilizada y el porcentaje del procesador utilizado.

Registros Porcentaje del procesador utilizado Porcentaje de Memoria RAM utilizada

1000 42.02 37.21

10000 58.93 44.48
100000 70.08 60.92
Tabla 4.6 – Resultados de SQL Server en consumo de recursos del servidor

Registros Porcentaje del procesador utilizado Porcentaje de Memoria RAM utilizada

1000 45.92 50.26

10000 61.37 67.47
100000 84.14 89.62
Tabla 4.7 – Resultados de MongoDB en consumo de recursos del servidor

4.5.2.2.Analisis de los resultados de las pruebas

Como podemos ver en las gráficas 4.3, 4.4 y 4.5 encontramos que la diferencia en el
desempeño entre ambas bases de datos en donde, igual que en las pruebas de inserción
MongoDB resulta ser mas rápido en comparación con SQL Server.

88
 Consultas para 1000 registros
16
13.6
14
12
10
8 6.47
6 4.731
4
2 1.28

0
Consultas escalares aleatorias Consultas de campos multiples

SQL Server MongoDB

Gráfica 4.3

Consultas para 10000 registros

200
176.805
180
160
140
120
100
80
51.29 54.714
60
40
15.23
20
0
Consultas escalares aleatorias Consultas de campos multiples

SQL Server MongoDB

Gráfica 4.4

89
 Consultas para 100000 registros
1200 1102.823

1000

800 689.83
637.24
600
398.02
400

200

0
Consultas escalares aleatorias Consultas de campos multiples

SQL Server MongoDB

Gráfica 4.5

En la gráfica 4.6 podemos encontrar una gráfica que nos ilustra sobre el la cantidad de
recursos que se utilizarón para poder generar las distintas iteraciones en el SQL Server.

USO DE RECURSOS PARA LAS

CONSULTAS DE LECTURA
Porcentaje del procesador utilizado Porcentaje de Memoria RAM utilizada
70.08

60.92
58.93

44.48
42.02

37.21

1000 10000 100000

Gráfica 4.6

90
Podemos entonces ver que entre mayor sea el número de lecturas mayor cantidad de recursos
consumira SQL Server en nuestra maquina virtual.

La gráfica 4.7 nos muestra el porcentaje de RAM y procesador que es utilizado por el
MongoDB, en esta grafica podemos encontrar porcentajes muy particulares que es
importante tomar en cuenta.

USO DE RECURSOS PARA LAS

CONSULTAS DE LECTURA
Porcentaje del procesador utilizado Porcentaje de Memoria RAM utilizada

89.62
84.14
67.47
61.37
50.26
45.92

1000 10000 100000

Gráfica 4.7

Si realizamos la comparación entre la grafica 4.6 y la grafica 4.7 encontramos que MongoDB
consume muchos mas recursos que SQL Server al momento de realizar este tipo de
iteraciones. Esto se debe principalmente a que MongoDB utilizará la memoria libre
disponible para el almacenamiento en caché. De la misma forma MongoDB realiza una
consulta a una base de datos a la vez.

91
4.6.Conclusiones de las pruebas de desempeño

 De los resultados obtenidos podemos decir que los mejores tiempos tanto en consultas
como en inersiones los tiene MongoDB en comparación contra SQL Server.

 MongoDB presenta tiempos rapidos debido a su sistema de nodos lo que hace que se
encuentren más formas o rutas para llegar a la información requerida, pero de igual
forma en procesos como lo son la escritura el sistema de MongoDB utilizara gran
cantidad de recursos.

 Es importante señalar que aunque SQL Server tiene tiempos mas lentos que
MongoDB, SQL Server nos ofrece una mejor consistencia en la integridad de los
datos haciendolo mas confiable.

 MongoDB se basa en la escritura de archivos asignados a la memoria en el disco y

vuelve tan pronto como la memoria se ha actualizado, pero antes de que el sistema
operativo ha terminado de sincronizar el archivo asignado en memoria.

SQL Server por al contrario genera resultados sólo después de que los datos se hayan
conectado de forma integra lo cual hace mas lento a SQL Server pero mas fiable.

92
 Conclusiones

El modelo relacional de base de datos ha sido el modelo predominante para sistemas de

almacenamiento de información en las ultimas decadas. Las bases de datos relacionales
ofrecen una solución robusta para el almacenamiento y gestion de datos, que estan
respaldados con una gran variedad de aplicaciones y herramientas de manejo de información,
ademas de una diversa mano de obra calificada para implementar y mantener soluciones en
premisas. Por otra parte en la ultima decada el modelo relacional que antes se creia que podia
englobar todas las necesidades posibles se vio afectado por las necesidades crecientes de
velocidad, por lo que las bases de datos no relacionales se empezaron a volver mas populares.
Por lo tanto hay mucho debate entre que modelo de base de datos es mejor.

El principal beneficio que se obtiene al momento de utilizar una base de datos NoSQL es la
flexibilidad de almacenar grandes cantidades de datos, si se llega a requerir campos extras o
informaciones extras no es necesario cambiar la estructura de la base de datos como ocurre
en las bases de datos relacionales. Las bases de datos NoSQL son esenciales para la
actualidad ya que todo gira al entorno de redes sociales y es ahí donde son utilizadas para
almacenar grandes cantidades de datos, las bases de datos NoSQL no quieren reemplazar las
bases de datos relacionales sino, dar otras alternativas para la fluidez, escalabilidad, rapidez
y agilidad a la hora de que se necesite guardar tanta información. Presentan una gran ventaja
a la hora de almacenar especialmente en la nube que ha tomado tantas fuerzas en estos últimos
años para almacenar información y eso no los presta las bases de datos NoSQL.

Este tipo de estructuras de almacenamiento y gestion de datos combinado con los nuevos
paradigmas de tecnologia como lo son las nubes informaticas o Clouds nos ayudan a poder
realizar nuevos desarrollos abajo costo con lo cual podemos obtener herramientas de primera.

Al utlilizar la plataforma de Windows Azure podemos lograr tener a nuestra disposición la

facilidad de crear maquinas virtuales variadas, hechas a nuestras necesidades. Creando
entonces las maquinas virtuales en el sistema pudimos ver los factores importantes en el
manejo de bases de datos relacionales y no relacionales en ambientes cloud a lo que podemos
decir que las bases de datos NoSQL permiten ganar más rendimiento del sistema mediante
la eliminación de una gran cantidad de comprobaciones de integridad, realizado por bases de
datos relacionales, a partir del nivel de base de datos.

93
 Trabajos Futuros

Este experimento sirve como base para realizar realizar distintos tipos de experimentos que
involucran bases de datos y entornos de nube como lo son:

 Creación a gran escala de bases de datos

 Comparaciones entre diversos tipos de bases de datos no relacionales contra bases
de datos relaciones
 Comparación de los diferentes gestores de bases de datos no relacionales.

Otros temas que pensamos podrian ampliarse en futuras investigaciones:

 Alta disponibilidad de bases de datos en entornos cloud

 Migración de una base de datos en premisas a una base de datos en Cloud
 Transformación de una base de datos relacional en una base de datos no relacional
utilizando sistemas de nube informatica.

94
 Recomendaciones

A la Universidad Tecnologica de Panamá:

 Motivar a los etudiantes a desarrollar trabajos de investigación a lo largo de su carrera.

 Incentivar a los estudiantes de la Facultad de Ingenieria en Sistemas Computacionales
a desarrollar trabajos de investigación en entornos de nube
 Actualizar los planes de estudio con mira de insertar materias enfocadas en temas que
se ven en el mercado, como lo es Cloud Computing.
 Adecuar las materias del plan de estudio a la realidad que vive el país, dando ejemplos
concretos a los estudiantes de modo que ellos puedan ver las necesidades y la
competencia que existe en el mercado global.

95
 Referencias Bibliograficas

[1] Velásquez, W. (16 de Enero de 2014). SlideShares.

http://academicae.unavarra.es/bitstream/handle/2454/10203/629103.pdf?sequence=1

[2] Ramírez Valenzo, M., Cuevas Valencia, R., & Martínez Castro, J. M. (2011).
INTEGRACIÓN DE BÚSQUEDAS DE TEXTO COMPLETO EN BASES DE DATOS
NOSQL. REVISTA VINCULOS, 81.

[3] Seguin, K. (2011). The Little MongoDB Book. Autoedición.

[4] Banker, Kyle (28 de marzo de 2011), MongoDB in Action (1st edición),Manning,

[5] Pirtle, Mitch (3 de marzo de 2011), MongoDB for Web Development (1st
edición), Addison-Wesley Professional, p. 360

[6] Martín, A., Chávez, S., Rodríguez, N., Valenzuela, A., & Murazzo, M. (2013). Bases de
Datos NoSql en Cloud Computing. 166.

[7] Montoro, S. (7 de Enero de 2011). La Pastilla Roja.

http://lapastillaroja.net/2011/01/adios-open-source-hola-cloud/

[8] Enríquez, O. Y., & Gracia del Busto, H. (2012). Bases de datos NoSQL.

[9] Díaz Sepúlveda, W. (2013). BASES DE DATOS NOSQL: LLEGARON PARA

QUEDARSE.

[10] Hassan, Qusay (2011). "Demystifying Cloud Computing"

[11] Alcaraz Calero, Jose M.; König, Benjamin; Kirschnick, Johannes (2012). "Cross-Layer
Monitoring in Cloud Computing". In Rashvand, Habib F.; Kavian, Yousef S. Using Cross-
Layer Techniques for Communication Systems

[12] "Windows Azure General Availability". The Official Microsoft Blog. Microsoft.

[13] Azure (Windows Azure) on GitHub". Github.com

[14] Microsoft Azure Trust Center. https://azure.microsoft.com/en-us/support/trust-center/

96
[15] Bases de datos relacionales y no relacionales. Nicola Strappazzon. 2 de febrero de 2015.
https://www.swapbytes.com/rdbms-vs-nosql-bases-de-datos-relacionales-no-relacionales/

[16] "DNS | Microsoft Azure". Azure.microsoft.com.

97