Está en la página 1de 43

19

de enero de 2017 CONCEPTUALIZACIÓN


DE BASES DE DATOS
Distribuidas, Cliente - Servidor,
Federadas, Paralelas, Portables,
Móviles.

Alcalá Juárez Anakaren


Bardales Espinal Gloria Angelina
Ceballos Alberto
Merchán Cardoza Elízabeth Daniela
Montes Estrada Ricardo
LANIA - MAESTRÍA EN COMPUTACIÓN APLICADA
Contenido
Base de datos ....................................................................................................... 4

Características de una base de datos .................................................................. 4

Tipos de bases de datos ....................................................................................... 4

1. Distribuidas ................................................................................................ 4

1.1. Tipos de BD ............................................................................................ 7

1.2. Características / principios ..................................................................... 8

1.3. Ventajas y desventajas ........................................................................ 10

1.4. Evolución .............................................................................................. 11

1.5. Gestores ............................................................................................... 12

2. Cliente - servidor ...................................................................................... 12

2.1. Tipos de arquitectura ............................................................................ 13

2.1.1. Arquitectura de 2 capas .................................................................... 13

2.1.2. Arquitectura de 3 capas .................................................................... 13

2.2. Componentes de la arquitectura .......................................................... 15

2.2.1. Arquitectura cliente - servidor ........................................................... 15

2.2.2. Motor de base de datos (Database enginer) .................................... 16

2.2.3. Cliente ............................................................................................... 16

2.2.4. Interfaz del programa de aplicación (API) ........................................ 16

2.3. Características / principios ................................................................... 16

2.4. Ventajas y desventajas ........................................................................ 17

2.5. Evolución .............................................................................................. 17

2.6. Gestores ............................................................................................... 17

3. Federadas ................................................................................................ 18

3.1. Características / principios ................................................................... 19

1
3.2. Arquitectura .......................................................................................... 20

3.2.1. Acoplamiento fuerte y débil .............................................................. 20

3.2.2. Arquitectura de referencia de 5 niveles de Sheth & Larson ............. 20

3.3. Ventajas y desventajas ........................................................................ 21

3.4. Evolución .............................................................................................. 21

3.5. Gestores ............................................................................................... 22

4. Paralelas .................................................................................................. 23

4.1. Características / principios ................................................................... 23

4.2. Arquitecturas paralelas de bases de datos .......................................... 24

4.3. Paralelismo ........................................................................................... 26

4.4. Ventajas y desventajas ........................................................................ 27

4.5. Evolución .............................................................................................. 28

4.6. Gestores ............................................................................................... 28

5. Portables .................................................................................................. 30

5.1. Características / principios ................................................................... 30

5.2. Ventajas y desventajas ........................................................................ 30

5.3. Evolución .............................................................................................. 31

5.4. Gestores ............................................................................................... 31

6. Móviles ..................................................................................................... 32

6.1. Sistemas de base de datos móviles ..................................................... 33

6.2. Características / funcionalidades ......................................................... 34

6.3. Componentes de una base de datos móvil .......................................... 34

6.4. Ventajas y desventajas ........................................................................ 35

6.5. Evolución .............................................................................................. 35

6.6. Gestores ............................................................................................... 36

2
Diagrama evolutivo ............................................................................................. 38

Tabla comparativa .............................................................................................. 39

Bibliografía .......................................................................................................... 41

3
Base de datos
Una base de datos en un conjunto de datos que debe estar relacionado entre sí.
Los datos deben estar agrupados y estructurados, de tal forma que se facilite el
acceso a ellos. Dicha colección contiene información relevante para una empresa u
organización de cualquier índole, puede ser salud, educación, gobierno, estadística,
entre otros.

Características de una base de datos


Entre otras, algunas características generales de una base de datos (BD) son:

ü Independencia de los datos


ü Reducción de la redundancia
ü Seguridad
ü Fácil visualización de los registros

Tipos de bases de datos


Existen muchos tipos, el presente trabajo solo abordará las siguientes:

1. Distribuidas
2. Cliente - servidor
3. Federadas
4. Paralelas
5. Portables
6. Móviles

Años atrás, se dieron otros tipos de bases de datos, como las jerárquicas y las
relacionales, en los años 60’s y 70’s, respectivamente, para los tipos de bases de
datos tocadas en este documento se tendrá el orden mencionado anteriormente.

1. Distribuidas
El soporte completo para las bases de datos distribuidas implica que una sola
aplicación debe ser capaz de operar de manera transparente sobre los datos que
están dispersos en una variedad de bases de datos diferentes, administradas por

4
una variedad de distintos DBMSs, ejecutadas en diversas máquinas diferentes,
manejadas por varios sistemas operativos diferentes y conectadas a una variedad
de redes de comunicación distintas; donde el término de manera transparente
significa que la aplicación opera desde un punto de vista lógico como si todos los
datos fueran manejados por un solo DBMS y ejecutados en una sola máquina. Un
ejemplo en la figura 1.

Figura 1 [DATE, C. J. 2001] Introducción a los sistemas de bases de datos 7ª Ed, [Cada máquina
opera como cliente y como servidor](p. 53), Pearson Educación, México.

Un sistema de base de datos distribuida consiste en una colección de sitios,


conectados por medio de algún tipo de red de comunicación, en el cual:

a) Cada sitio es un sistema de base de datos completo por derecho propio, pero
b) Los sitios han acordado trabajar juntos, a fin de que un usuario de cualquier
sitio pueda acceder a los datos desde cualquier lugar de la red, exactamente
como si los datos estuvieran guardados en el propio sitio del usuario.

De aquí deducimos que la llamada "base de datos distribuida" es en realidad un tipo


de base de datos virtual cuyas partes componentes están almacenadas en varias
bases de datos "reales" distintas que se encuentran en varios sitios distintos (de
hecho, es la unión lógica de esas bases de datos reales). La figura 2 muestra un
ejemplo.

5
Figura 2 [DATE, C. J. 2001] Introducción a los sistemas de bases de datos 7ª Ed, [Un sistema de
base de datos distribuida típico](p.652), Pearson Educación, México.

El sistema de base de datos distribuida puede ser considerado como un tipo de


sociedad entre los DBMSs locales en cada uno de los sitios locales; un nuevo
componente de software en cada sitio —de manera lógica, una extensión del DBMS
local— proporciona la funcionalidad de sociedad necesaria, y es la combinación de
este nuevo componente y el DBMS existente, lo que constituye lo que generalmente
llamamos sistema de administración de base de datos distribuida.

Entonces, llamamos base de datos distribuidas a los fragmentos que se encuentran


almacenados en lugares distintos. Estos sitios constan con una computadora y un
DBMS (o SGBD, Sistema Gestor de Base de Datos), para administrar la base local
situada, conectándose entre sí aquellos fragmentos de una base distribuida por
medio de una red de comunicación.

Al momento de surgir una petición de consulta de cualquier sitio, el administrador


general de la base de datos, analiza esta petición y determina qué tipo de base de
datos distribuidas (fragmentos) se puede necesitar.

6
Las BD pueden ser:

ü Homogéneas: Todos los sitios tienen el mismo SGBD, son conscientes de la


existencia de los demás sitios y cooperan en el procesamiento de las
solicitudes. Los sitios locales mantienen un mismo esquema y SGBD.
ü Heterogéneas: Cada sitio puede tener un SGBD distinto, así como esquemas
diferentes. Puede que algunos sitios no conozcan a otros. Puede que solo
ofrezcan facilidades limitadas para la cooperación en el procesamiento de
transacciones.

¿Por qué son necesarias las bases de datos distribuidas?

La respuesta básica a esta pregunta es que las empresas ya están generalmente


distribuidas, al menos de manera lógica (en divisiones, departamentos, grupos de
trabajo, etcétera) y es muy probable que también lo estén de manera física (en
plantas, fábricas, laboratorios, etcétera); de esto deducimos que por lo general
también los datos ya están distribuidos, ya que cada unidad organizacional dentro
de la empresa mantendrá naturalmente los datos que son importantes para su
propia operación.

1.1. Tipos de BD
ü Centralizadas, es muy similar al modelo cliente-servidor en el sentido que la
BDD está centralizada en un lugar y los usuarios están distribuidos. Este
modelo solo brinda la ventaja de tener el procesamiento distribuido ya que
en sentido de disponibilidad y fiabilidad no se gana nada.
ü Replicadas, el esquema de BDD de replicación consiste en que cada nodo
debe tener su copia completa de la BD. Es fácil de ver que este esquema
tiene un alto costo en el almacenamiento de la información, un alto costo de
escritura puesto que la actualización de los datos debe ser realizada en todas
las copias.
ü Particionadas, consiste en que solo hay una copia de cada elemento, pero la
información está distribuida a través de nodos, en cada nodo se aloja uno o
más fragmentos disjuntos de la BD. La fragmentación se puede realizar de
tres formas:

7
• Horizontal
• Vertical
• Mixto
ü Híbrida, representa la combinación del esquema de partición y replicación.
Se particiona la relación y a la vez los fragmentos están selectivamente
replicados a través de BDD.

1.2. Características / principios


1.2.1. Autonomía local
La autonomía local significa que todas las operaciones en un sitio dado están
controladas por ese sitio, la autonomía local también implica que los datos locales
son poseídos y administrados localmente con contabilidad local: todos los datos
pertenecen "realmente" a alguna base de datos local, aun cuando estén accesibles
desde otros sitios remotos. Por lo tanto, la seguridad, integridad y representación
de almacenamiento de los datos locales permanecen bajo el control y jurisdicción
del sitio local.

1.2.2. No dependencia de un sitio central


La autonomía local implica que todos los sitios deben ser tratados como iguales.
Por lo tanto, no debe haber particularmente ninguna dependencia de un sitio
"maestro" central para algún servicio central.

1.2.3. Operación continua


Los apagados no planeados son obviamente indeseables, ¡pero es difícil evitarlos!
Por el contrario, los apagados planeados nunca deberían ser requeridos.

1.2.4. Independencia de ubicación


Los usuarios no tienen que saber dónde están almacenados físicamente los datos,
sino que deben ser capaces de comportarse —al menos desde un punto de vista
lógico— como si todos los datos estuvieran almacenados en su propio sitio local.

8
1.2.5. Independencia de fragmentación
La fragmentación es necesaria por razones de rendimiento: los datos pueden estar
almacenados en la ubicación donde son usados más frecuentemente para que la
mayoría de las operaciones sean locales y se reduzca el tráfico en la red.

1.2.6. Independencia de replicación


Un sistema maneja réplica de datos si una relación dada se puede representar en
el nivel físico mediante varias copias réplicas, en muchos sitios distintos. La réplica
es deseable al menos por dos razones: en primer lugar, puede producir un mejor
desempeño (las aplicaciones pueden operar sobre copias locales en vez de tener
que comunicarse con sitios remotos); en segundo lugar, también puede significar
una mejor disponibilidad (un objeto estará disponible para su procesamiento en
tanto esté disponible por lo menos una copia, al menos para propósitos de
recuperación).

1.2.7. Procesamiento de consultas distribuidas


Este manejo de datos en las consultas permite las consultas eficientes desde
diferentes usuarios con las características que determine el sistema; la consulta de
datos es más importante en un sistema distribuido que en uno centralizado. Lo
esencial es que, en una consulta donde están implicados varios sitios, habrá
muchas maneras de trasladar los datos en la red de cómputo para satisfacer la
solicitud, y es crucial encontrar una estrategia suficiente.

1.2.8. Administración de transacciones distribuidas


Este manejo tiene dos aspectos principales, el control de recuperación y el control
de concurrencia, cada uno de los cuales requiere un tratamiento más amplio en el
ambiente distribuido. En un sistema distribuido, una sola transacción puede implicar
la ejecución de programas o procesos en varios sitios (en particular puede implicar
actualizaciones en varios sitios). Por esto, cada transacción está compuesta de
varios agentes, donde un agente es el proceso ejecutado en nombre de una
transacción dada en determinado sitio.

9
1.2.9. Independencia de hardware
1.2.10. Independencia de sistema operativo
1.2.11. Independencia de red
1.2.12. Independencia de DBMS
En la independencia con respecto a su manejo, se requiere que los SGBD en los
diferentes sitios manejan todos la misma interfaz; no necesitan ser, por fuerza,
copias del mismo sistema.

1.3. Ventajas y desventajas


Ventajas Desventajas
ü La confiabilidad: la probabilidad de que el ü Costo y complejidad del
sistema esté listo y funcionando en software, dado que se requiere
cualquier momento dado; ya que los un software más complejo para
sistemas distribuidos no son una ambientes distribuidos.
propuesta de todo o nada. ü Mayor procesamiento para
ü Estructura organizacional: los fragmentos intercambiar mensajes entre
de la base de datos se ubican en los las localidades.
departamentos a los que tienen relación. ü Integridad de los datos, dado
ü Fiabilidad y disponibilidad: la probabilidad que es más difícil controlar por
de que el sistema esté listo y funcionando las múltiples y dispersas copias
continuamente a lo largo de un período de los datos.
especificado. ü Baja velocidad de respuesta si
ü Utilización compartida de datos. los datos y la aplicación no
ü Control local de los datos: lo que tiende a están distribuidos
promover mejoras en la integridad y la apropiadamente de acuerdo
administración de los datos. con su uso.
ü Reducción de tráfico en la comunicación
de datos.
ü Agilización del procesamiento de
consultas.

10
ü Alta velocidad de respuesta dado que la
mayoría de las aplicaciones usan datos
locales.
ü Crecimiento incremental y modular de las
aplicaciones y las bases de datos sin
interrupciones para los usuarios
existentes.
Tabla 1. Ventajas y desventajas de bases de datos distribuidas.

1.4. Evolución
La necesidad de almacenar datos de forma masiva dio paso a la creación de los
sistemas de bases de datos. En 1970 Edgar Frank Codd escribió un artículo con
nombre: «A Relational Model of Data for Large Shared Data Banks» («Un modelo
relacional para grandes bancos de datos compartidos»). Con este artículo y otras
publicaciones, definió el modelo de bases de datos relacionales y reglas para poder
evaluar un administrador de bases de datos relacionales.

Inicio de las bases de datos distribuidas-1980

Originalmente se almacenaba la información de manera centralizada, pero con el


paso del tiempo las necesidades aumentaron y esto produjo ciertos inconvenientes
que no era posible solucionarlos o volverlos eficientes de la forma centralizada.
Estos problemas impulsaron la creación de almacenamiento distribuido, los cuales
hoy en día proveen características indispensables en el manejo de información, es
decir, la combinación de las redes de comunicación y las bases de datos.

Hay varios factores que han hecho que las bases de datos evolucionen a bases de
datos distribuidas. En el mundo de los negocios se ha dado una globalización y a la
vez las operaciones de las empresas son cada vez más descentralizadas
geográficamente. También el poder de las computadoras personales aumentó y el
costo de los Mainframes ya no tenía sentido. Además, la necesidad de compartir
datos ha hecho que crezca el mercado de las bases de datos distribuidas.

11
1.5. Gestores
Para que un sistema distribuido sea exitoso, debe ser relacional; la tecnología
relacional es un requisito previo para la tecnología distribuida.

Implementaciones comerciales. La mayoría de los productos SQL actuales


proporcionan algún tipo de soporte de base de datos distribuida (con diversos
grados de funcionalidad, por supuesto). Algunos de los más conocidos incluyen (a)
Ingres/Star, el componente de base de datos distribuida de Ingres; (b) la opción de
base de datos distribuida de Oracle; y (c) Impropiedad de datos distribuidos de DB2.

Se han llegado a necesitar y desarrollar diversas implantaciones / prototipos como


sistemas de investigación:

ü SDD-1 (Sistema para la distribución de base de datos) de la corporación


americana: sistemas relacionales en distintos lugares conectados por medio
de las redes de comunicación
ü IMS / MSC (Sistema de gestión de la información / Múltiples sistemas de
acoplamiento) de IMB: el MSC permite la intercomunicación de dos o más
sistemas de base de datos de IMS
ü CICS / ISC (Sistema del control de la información del cliente / Sistema de
comunicación Internacional) de IBM: ISC conecta dos o más sistemas CICS.

2. Cliente - servidor
Es un modelo para el desarrollo de sistemas de información en el que las
transacciones se dividen en procesos independientes que cooperan entre sí para
intercambiar información, servicios o recursos. Se denomina cliente al proceso que
inicia el dialogo o solicita los recursos y servidor al proceso que responde a las
solicitudes. (Silberschatz, Korth, & Sudarshan, S. (Instituto Indio de Tecnología,
2002).

12
2.1. Tipos de arquitectura
2.1.1. Arquitectura de 2 capas
Esta arquitectura consta de tres componentes distribuidos en 2 capas: cliente
(solicitante de servicios) y servidor (proveedor de servicios). (Mendoza Gonzalez,
2010). Los tres componentes son:

ü Interfaz del usuario


ü Gestión del procesamiento
ü Gestión de la base de datos

Hay 2 tipos de arquitecturas de 2 capas:

ü ThinClient / FatServer
ü FatClient / ThinServer

Figura 3 Arquitectura de 2 capas.

2.1.2. Arquitectura de 3 capas


Esta arquitectura surgió para superar las limitaciones de la arquitectura de 2 capas.
Usando una tercera capa (servidor intermedio) que se encuentra entre la interfaz
del usuario (cliente) y el gestor de datos (servidor). La capa intermedia proporciona
gestión del procesamiento y en se ejecutan las reglas y lógica de procesamiento.

13
Figura 4 Arquitectura de 3 capas.

Las tecnologías que se emplean son ADO (ActiveX Data Object) implementada por
Microsoft y JDBC (Java Data Base Connectivity) implementada por Sun
Microsistems, teniendo las siguientes características:
ADO JDBC
ü Tiene la principal función de realizar la ü Tiene la función de ser un gestor para
solicitud de los datos a la base de datos. la aplicación con respecto a la base de
ü Esta solicitud la realizará mediante la datos.
tecnología OLE DB, la cual estará en ü Por primera vez el JDBC fue empleado,
contacto de manera directa con la base tomando como intermediario entre él y
de datos. la base de datos al ODBC.
ü La tecnología OLE DB sólo se empleará ü Como modelo cliente/servidor, el JDBC
cuando el DBMS pertenece de igual se encontrará trabajando en el equipo
manera a Microsoft, como es SQL cliente, conectándose directamente
Server. con la base de datos.
ü Como modelo de tres capas, el JDBC
se encontrará en una capa intermedia,

14
ü ADO encapsulará a ciertos objetos de donde todos los usuarios pasarán por
OLE DB, para que, de esta manera, se él para poder accesar a la base de
realice la conexión con la base de datos. datos.
ü Para realizar la gestión de acceso a ü Existen módulos JDBC que son propios
bases de datos heterogéneas por parte de los fabricantes de DBMS, que son
de ADO, éste hará uso de ciertos objetos utilizados para el rápido acceso a la
de la tecnología RDO (Remote Data información de las bases de datos de
Objects). los mismos.
ü RDO dependerá de los ODBC’s para ü JDBC no se encontrará ligado a
poder efectuar la conexión a la base de trabajar con alguna tecnología en
datos y con esto el acceso a la específica, ya que se elaboró con la
información. finalidad de ser portable.
ü ADO podrá encontrarse trabajando en ü En aplicaciones Web, JDBC se
una página web en conjunto con código encontrará laborando en conjunto con
HTML; esto será posible mediante un código HTML, mediante el mecanismo
mecanismo de introducción de de Java script.
instrucciones como es el VBscript. ü JDBC se elaboró con la finalidad de
ü Los objetos que conforman al ADO, no poder ser compatible y portable para
son compatibles con otros lenguajes, poder ser empleado en aplicaciones y
solo por aquellos que pertenecen a la para la conexión con bases de datos.
empresa Microsoft como son: Visual
C++, Visual Basic, Visual Java, etc.
Tabla 2. Descripción tecnologías ADO y JDBC.

2.2. Componentes de la arquitectura


2.2.1. Arquitectura cliente - servidor
Es un ambiente computacional basado en una red (LAN o WAN) en la que un
servidor central de base de datos, o un “motor” o “dispositivo”, maneja todos los
comandos de base de datos enviados a él desde las estaciones de trabajo cliente,
y aplicaciones de programas en cada cliente concentran las funciones de interfaz
con el usuario. (Mendoza, n.d.).

15
2.2.2. Motor de base de datos (Database enginer)
La parte (back-end) del sistema de base de datos cliente/servidor que se encuentra
en el servidor y provee el procesamiento de la base de datos y comparte las
funciones de acceso.

2.2.3. Cliente
La parte (front-end) del sistema de base de datos cliente/servidor que provee la
interfaz del usuario y las funciones de manipulación de datos.

2.2.4. Interfaz del programa de aplicación (API)


Software que le permite a una plataforma de desarrollo programas específicos front-
end comunicarse con un “motor” de base de datos particular, cuando las partes
front-end y back-end no han sido construidas para ser compatibles.

Figura 5 Componentes de la arquitectura Cliente - Servidor.

2.3. Características / principios


Entre las principales características de la arquitectura cliente/servidor se pueden
destacar las siguientes:

ü El servidor presenta a todos sus clientes una interfaz única y bien definida.
ü El cliente no necesita conocer la lógica del servidor, solo su interfaz externa.
ü El cliente no depende de la ubicación física del servidor, ni del tipo de equipo
físico en el que se encuentra, ni de su sistema operativo.
ü Los cambios en el servidor implican pocos o ningún cambio en el cliente.

16
2.4. Ventajas y desventajas
Ventajas Desventajas
ü Permite mayor procesamiento de ü Alta complejidad tecnológica
información en el sitio donde ésta es al tener que integrar una gran
generada, mejorando los tiempos de variedad de productos.
respuesta y reduciendo el tráfico de la red. ü Los problemas de saturación
ü Facilita el uso de interfaces gráficas para en la red pueden bajar el
los usuarios y permite el trabajo con rendimiento del sistema por
aplicaciones de presentaciones visuales en debajo de lo que se obtendría
las estaciones de trabajo. con una sola maquina
ü Permite y promueve la utilización de (arquitectura centralizada).
sistemas abierto. ü Es más difícil asegurar un
ü Menos costos de operación. elevado grado de seguridad
ü Más factible la escalabilidad del sistema. en una red de clientes y
servidores que en un sistema
con un único ordenador
centralizado.
Tabla 3. Ventaja y desventajas de bases de datos cliente - servidor.

2.5. Evolución
En los años 90’s con el surgimiento de la necesidad de relacionar varias
aplicaciones que gestionen BD en las empresas, se da lugar a las bases de datos
distribuidas, implementándose la arquitectura cliente - servidor.

2.6. Gestores
ü PostgreSQL: su año de lanzamiento fue en 1982 y su última versión fue la
9.6.1.

Características:

• Amplia variedad de tipos nativos.


• Maneja Triggers.
• Creación de vistas.
• Integridad transaccional.

17
• Herencia de tablas.
• Alta concurrencia
• Soporte para transacciones distribuidas.
ü SQL Server: su año de lanzamiento fue en 1989 y su última versión fue la del
2016.

Características:

• Rendimiento: Análisis operativo en tiempo real.


• Disponibilidad: Migración dinámica y soporte de virtualización
mejorados.
• Seguridad: Enmascaramiento dinámico de datos.
• Programación: compatibilidad con JSON.
• Preparación para la nube: Copias de seguridad en Azure.
• Administración: basada en directivas.
• Inteligencia de negocios: Informes modernizados.
• Análisis avanzado: procesamiento multiproceso de consultas R y
memoria de streaming.
ü MySQL: su año de lanzamiento fue en 1995 y su última versión es la 5.7.
Caracteristicas:
• Disponibilidad en gran cantidad de plataformas y sistemas.
• Conectividad segura.
• Replicación.
• Búsqueda e indexación de campos de texto.
• Amplio subconjunto de lenguajes SQL.
• Posibilidad de selección de mecanismos de almacenamiento.

3. Federadas
Es una colección de sistemas de base de datos cooperativas y autónomas, que
permiten compartir todos o algunos sus datos. En un sistema federado los usuarios
tienen acceso a los datos, de los distintos sistemas, a través de una interfaz común,

18
sin embargo, no existe un esquema global que describa a todos los datos de las
distintas bases de datos, en su lugar hay varios esquemas unificados, cada uno
describiendo porciones de bases de datos y archivos para el uso de cierta clase de
usuarios. (Ramos Salavert Isidro, 2000).

El papel de las bases de datos federas estriba en aceptar una consulta,


descomponerla internamente en (sub)consultas a las bases de datos relevantes,
pasar estas consultas a los Sistemas de Gestión de Base de Datos
correspondientes, obtener las respuestas, traducirlas en su caso, consolidarlas y
presentar esa única respuesta consolidada al usuario en el formato deseado. No
son los datos los que se integran, sino el acceso.

Figura 6 Sistema de bases de datos federadas.

3.1. Características / principios


ü Heterogeneidad: se dice que es heterogénea debido a que los sistemas de
bases de datos que lo forman pueden tener cualquier arquitectura.
ü Autonomía: esta propiedad se cumple ya que cada sistema de base de datos
funciona por sí mismo y de forma local.
ü Distribución: hace referencia a que cada sistema de base de datos puede
estar localizado en cualquier punto.
19
3.2. Arquitectura
3.2.1. Acoplamiento fuerte y débil
ü Fuerte: Cuando se constituye un administrador de la federación, el cual
negocia con los administradores de las bases de datos componentes, todas
las decisiones importantes para la construcción y funcionamiento del sistema
federado. Siendo estos administradores los que solucionan los problemas de
heterogeneidad.
ü Débil: Cuando no se cuenta con un administrador de la federación y son los
usuarios de nivel federado, quienes deben de averiguar en qué base de datos
están los datos que les interesan, teniendo que resolver los problemas de
heterogeneidad, y ser capaces de formular su consulta e interpretar el
resultado.

3.2.2. Arquitectura de referencia de 5 niveles de Sheth & Larson

Figura 7 Arquitectura de 5 niveles de Sheth y Larson.

ü Esquema Local: es el esquema conceptual de los componentes.


ü Esquema componente: es derivado de trasladar el esquema local en un
modelo de datos llamado canónico o modelo de datos común.

20
ü Esquema de exportación: representa un subconjunto de la totalidad de los
datos que contiene el esquema de componente. Este subconjunto de datos
es el que se requiere compartir en la base de datos federada.
ü Esquema federado: es una integración de múltiples esquemas de
exportación de cada base de datos componente.
ü Esquema externo: representa una vista hacia un usuario o conjunto de
usuario determinado.

3.3. Ventajas y desventajas


Ventajas Desventajas
ü Permite conectar diferentes sistemas ü Solo son accesibles desde
de gestores de base de datos, que equipos fijos conectados a la
conforman una sola base de datos. infraestructura del sistema de
ü Cuando es un entorno homogéneo las base de datos.
bases de datos federadas pueden ü Cada componente de base de
ayudar a distribuir la carga de grandes datos es un punto potencial de
bases de datos. fallo.
ü Los fuertemente acoplados tienen ü Las fuertemente acopladas no
capacidad se soportar actualizaciones. soportan la evolución dinámica de
ü Los débilmente acopladas disponen de los esquemas de exportación o
gran flexibilidad para mapear componentes.
diferentes semánticas de los mismos ü Las débilmente acopladas tienen
objetos en distintos esquemas de problemas para actualizar las
exportación. vistas que utilizan los usuarios.
Tabla 4. Ventajas y desventajas de bases de datos federadas.

3.4. Evolución
El concepto de manejadores de base de datos federados empieza 30 años después
de la aparición de las primeras bases de datos, siendo entonces, la aparición de las
bases de datos federadas en los años 90’s.

“Aunque el concepto de bases de datos federadas viene de Hammer y McLeod en


1979 y luego retomado en 1985 por Heimbigner y McLeod y posteriormente en
1990 y 1991 por Sheth y Larson y luego por Saltor” (Ramirez, 2014).

21
3.5. Gestores
Un sistema federado es un tipo especial de sistema de gestión de base de datos
(DBMS) distribuidas. Un sistema federado consta de una instancia de DB2 que
actúa como un servidor federado, una base de datos que actúa como base de datos
federada, uno o varios orígenes de datos y clientes (usuarios y aplicaciones) que
acceden a la base y a los orígenes de datos.

Figura 8 Componentes de un sistema de base de datos federada.

La potencia de un sistema federado se basa en su capacidad para:

ü Correlacionar datos locales y orígenes de datos remotos, como si todos los


datos se almacenaran localmente en la base de datos federada.
ü Actualizar datos en orígenes de datos relacionales, como si todos los datos
se almacenaran en bases de datos federadas.
22
ü Mover datos desde los orígenes de datos relacionales y hacia estos orígenes
de datos.
ü Aprovechar la potencia de proceso de orígenes de datos, enviando
solicitudes a los orígenes de datos para que se procesen.
ü Compensar limitaciones SQL en los orígenes de datos procesando partes de
una solicitud distribuida en el servidor federado.

4. Paralelas
El concepto de paralelismo en las bases de datos se puede definir como la partición
de la base de datos para poder procesar de forma paralela, en distintos discos y con
distintos procesadores, una sola operación sobre la base de datos.

La tecnología de bases de datos paralelas promete mejoras en el desempeño y la


alta disponibilidad, pero con problemas de interoperabilidad si no se administra de
forma apropiada.

4.1. Características / principios


4.1.1. Diseño de la base de datos paralela
Se debe considerar el problema de cómo distribuir la información entre los diferentes
nodos de la base de datos paralela (BDP). Los dos aspectos a tratar en el diseño
de la BDP son: fragmentación y distribución.

4.1.2. Procesamiento de consultas


En el procesamiento de consultas en BDP se tiene que considerar el procesamiento
de una consulta y además el costo involucrado en la transmisión de información
entre los diferentes nodos para la obtención de los resultados de la consulta que se
solicitó.

4.1.3. Control de concurrencia


El control de concurrencia es la actividad de coordinar accesos concurrentes a la
base de datos. Un aspecto interesante del control de concurrencia es el manejo de
interbloqueos. El sistema no debe permitir que dos o más transacciones se
bloqueen entre ellas.

23
4.1.4. Confiabilidad
Se deben ofrecer garantías de que la información es confiable. En sistemas
paralelos, el manejo de la atomicidad y durabilidad de las transacciones es aún más
complejo, pues una sola transacción puede involucrar dos o más fragmentos de la
BDP.

4.2. Arquitecturas paralelas de bases de datos


4.2.1. Memoria compartida
En una arquitectura de memoria compartida los procesadores y los discos tienen
acceso a una memoria común, normalmente a través de un bus o de una red de
interconexión.

Figura 9 Arquitectura de memoria compartida.

El beneficio de la memoria compartida es la extremada eficiencia en cuanto a la


comunicación entre procesadores; cualquier procesador puede acceder a los datos
de la memoria compartida sin necesidad de la intervención del software.

El inconveniente de las máquinas con memoria compartida es que la arquitectura


no puede ir más allá de 32 o 64 procesadores porque el bus o la red de interconexión
se convertirían en un cuello de botella.

4.2.2. Disco compartido


En el modelo de disco compartido todos los procesadores pueden acceder
directamente a todos los discos a través de una red de interconexión, pero los
procesadores tienen memorias privadas.

24
Figura 10 Arquitectura de disco compartido.

Las arquitecturas de disco compartido ofrecen dos ventajas respecto de las de


memoria compartida. Primero, el bus de la memoria deja de ser un cuello de botella,
ya que cada procesador dispone de memoria propia. Segundo, esta arquitectura
ofrece una forma barata para proporcionar una cierta tolerancia ante fallos.

El problema principal de los sistemas de discos compartidos es la ampliabilidad. La


interconexión con el subsistema de discos es ahora el nuevo cuello de botella; esto
es especialmente grave en situaciones en las que la base de datos realiza un gran
número de accesos a los discos.

4.2.3. Sin compartimiento


En un sistema sin compartimiento cada nodo de la máquina consta de un
procesador, memoria y uno o más discos. Los procesadores de un nodo pueden
comunicarse con un procesador de otro nodo utilizando una red de interconexión de
alta velocidad. Un nodo funciona como el servidor de los datos almacenados en los
discos que posee.

Figura 11 Arquitectura sin compartimiento.

El modelo sin compartimiento salva el inconveniente de requerir que todas las


operaciones de E/S vayan a través de una única red de interconexión, ya que las
referencias a los discos locales son servidas por los discos locales de cada

25
procesador. Las arquitecturas sin compartimiento son más ampliables y pueden
soportar con facilidad un gran número de procesadores.

El principal inconveniente de los sistemas sin compartimiento es el coste de


comunicación y de acceso a discos remotos, coste que es mayor que el que se
produce en las arquitecturas de memoria o disco compartido, ya que el envío de
datos provoca la intervención del software en ambos extremos.

4.2.4. Jerárquica
La arquitectura jerárquica combina las características de las arquitecturas de
memoria compartida, de disco compartido y sin compartimiento. A alto nivel el
sistema está formado por nodos que están conectados mediante una red de
interconexión y que no comparten ni memoria ni discos. Así, el nivel más alto es una
arquitectura sin compartimiento.

Figura 12 Arquitectura jerárquica.

Hoy en día los sistemas paralelos comerciales de bases de datos pueden ejecutarse
sobre varias de estas arquitecturas.

4.3. Paralelismo
Al abaratarse los microprocesadores, las máquinas paralelas se han vuelto
comunes y relativamente baratas.

El paralelismo se utiliza para proporcionar aceleración, y las consultas se ejecutan


más rápido debido a que se proporcionan más recursos, como procesadores y
discos. El paralelismo también se utiliza para proporcionar ampliabilidad, y las
cargas de trabajo crecientes se tratan sin aumentar el tiempo de respuesta mediante
un aumento en el grado de paralelismo.

26
4.3.1. Paralelismo de E/S
El paralelismo de E/S se refiere a la reducción del tiempo necesario para recuperar
relaciones del disco dividiéndolas en varios discos.

4.3.2. Paralelismo entre consultas


En el paralelismo entre consultas se ejecutan en paralelo entre sí diferentes
consultas o transacciones. El uso principal del paralelismo entre consultas es
ampliar los sistemas de procesamiento de transacciones para permitir un número
mayor de transacciones por segundo.

4.3.3. Paralelismo en consultas


El paralelismo en consultas se refiere a la ejecución en paralelo de una única
consulta en varios procesadores y discos. El uso del paralelismo en consultas es
importante para acelerar las consultas de ejecución larga.

La ejecución de una sola consulta puede hacerse en paralelo de dos maneras:


Paralelismo en operaciones y paralelismo entre operaciones.

4.3.4. Paralelismo en operaciones


Se puede acelerar el procesamiento de consultas haciendo paralela la ejecución de
cada una de las operaciones, como puede ser la ordenación, la selección, la
proyección y la reunión.

4.3.5. Paralelismo entre operaciones


Se puede acelerar el procesamiento de consultas ejecutando en paralelo las
diferentes operaciones de las expresiones de las consultas.

Hay dos formas de paralelismo entre operaciones: el paralelismo de encauzamiento


y el paralelismo independiente.

4.4. Ventajas y desventajas


Ventajas Desventajas
ü Aceleración. ü Posibles problemas de
ü Escalamiento. interoperabilidad.
ü Disponibilidad. ü Alto costo.

27
ü Escalabilidad para mejoras de
rendimiento predictivas.
Tabla 5. Ventajas y desventajas de bases de datos paralelas.

4.5. Evolución
Las bases de datos paralelas se empezaron a desarrollar alrededor de 1980,
especialmente con el proyecto Gamma, un sistema de base de datos sobre una
serie de procesadores de propósito general funcionando en paralelo. Este sistema
es en el que se inspiran la mayoría de sistemas paralelos de IBM, Tandem, Oracle,
Informix, Sybase y AT&T. Además, el uso de sistemas paralelos para la minería de
datos es uno de los campos de investigación más activos actualmente.

Los sistemas de bases de datos paralelos, como casi toda la tecnología paralela,
fue acuñada como la tecnología del futuro en cuanto a altas prestaciones. Hoy en
día la postura es más realista y se reconoce su uso en sistemas de muy altas
prestaciones.

EI primer SGBD paralelo fue Teradata en 1992 con la base de datos de Wal-Mart.
A finales de los ochenta, la versión 6 de Oracle también disponía de soporte SMP
(multiprocesamiento simétrico) para procesamiento de transacciones y de cluster
para máquinas Vax de Digital. En 1991 Oracle y nCube publicaron resultados de
1000TPS y el resto de los fabricantes también crearon versiones paralelas como
Ingres sobre máquinas Sequent o Informix, que reescribió su motor para adecuarse
a estas nuevas arquitecturas.

4.6. Gestores
Un Sistema de Gestión de Bases de Datos paralelas es un SGBD capaz de utilizar
recursos de cómputo altamente acoplados (procesadores, discos y memoria). El
acoplamiento se consigue mediante redes con un tiempo de intercambio de datos
comparable al tiempo de intercambio de datos con un disco.

ü Ejemplos de prototipos:
• EDS and DBS3 (ESPRIT)
• Gamma (U. de Wisconsin)
• Bubba (MCC, Austin, Texas)
28
• XPRS (U. de Berkeley)
• GRACE (U. de Tokyo)
ü Ejemplos de productos:
• Teradata (NCR)
• NonStopSQL (Tandem-Compac)
• DB2 (IBM), Oracle, Informix, Ingres, Navigator (Sybase) ...
ü Tecnología comercial de bases de datos paralelas:
• Oracle Real Application Clusters

Oracle Real Application Clusters (RAC) requiere un clúster de hardware subyacente,


un grupo de servidores independientes que cooperan como un solo sistema. Los
principales componentes de clúster son los nodos de procesador, un clúster de
interconexión y un subsistema de almacenamiento compartido. Cada nodo de
servidor tiene su propia instancia de base de datos con un proceso de escritura de
registro, un proceso de escritura de base de datos y un área global compartida que
contiene bloques de base de datos, búferes de reelaboración de registro,
información de diccionario y enunciados SQL compartidos. Todos los procesos de
escritura de bases de datos en un clúster usan el mismo sistema de
almacenamiento compartido. Cada instancia de base de datos mantiene sus propios
registros de recuperación.

• IBM DB2 Enterprise Server Edition con la opción DPF

La Database Partitioning Feature (DPF) proporciona procesamiento paralelo estilo


CN para bases de datos DB2. DB2 sin la opción DPF soporta procesamiento
transparente de bases de datos paralelas para máquinas multiprocesador. Los
planes de acceso DB2 pueden explotar todos los CPU y los discos físicos en un
servidor multiprocesador. La opción DPF agrega la capacidad de particionar una
base de datos a través de un grupo de máquinas. Una sola imagen de una base de
datos puede abarcar múltiples máquinas y aun así aparecer a los usuarios y
aplicaciones como una sola imagen de base de datos. El paralelismo particionado
disponible con la opción DPF proporciona mucho mayor escalabilidad que el
paralelismo multiprocesador solo.

29
Particionar con la opción DPF es transparente a los usuarios y aplicaciones. La
interacción con el usuario ocurre a través de una partición de base de datos,
conocida como nodo coordinador para dicho usuario. La partición de base de datos
a la que un cliente o aplicación se conecta se convierte en el nodo coordinador. Los
usuarios deben distribuirse a través de servidores para distribuir la función de
coordinador.

5. Portables
Una base de datos portable es aquella que tiene la capacidad de ser ejecutada en
diferentes plataformas con pocas modificaciones. Dichas DB son el conjunto de la
unión de muchos archivos y carpetas comprimidas en un solo archivo, el cual tiene
como objetivo ejecutarse fácilmente en el dispositivo cliente, sin necesidad de
instalar la aplicación o gestor de base de datos, tal y como se plantea en la página
de Valencia, (2016) con el gestor DATA.

Existen aplicaciones como SQL server que permiten crear DB portables. Con este
tipo de DBSM y algunos más, se corre el riesgo de no tener conexión efectiva en
caso de tener varias terminales, además, para su efectivo funcionamiento se deben
reunir todas las librerías y carpetas necesarias, de lo contrario puede no funcionar
bien o simplemente no se ejecutan.

5.1. Características / principios


ü No tiene instalación.
ü Son de poco tamaño, por lo tanto, son fáciles de llevar o transferir a un
dispositivo de almacenamiento.
ü Están listas para ser ejecutadas con sólo hacer doble clic.

5.2. Ventajas y desventajas


Ventajas Desventajas
ü No utiliza mucho espacio en el ü Pocos DBMS crean DB portables.
disco duro. ü No son auto actualizables.
ü Poco robustas.

30
ü El host no necesita ü No hay conexión con más dispositivos.
requerimientos altos para su ü No tiene la información actualizada.
ejecución. ü Poco seguras.
ü La lectura es más rápida. ü No se puede restringir el acceso a sus
ü No consume muchos recursos datos.
en el registro. ü No cuenta con herramientas para
ü Se pueden usar de inmediato. proveer integridad a la información.
ü Se pueden utilizar en
computadores congelados.
Tabla 6. Ventajas y desventajas de bases de datos portables.

5.3. Evolución
Acerca de la evolución de las bases de datos móviles no se tiene mucha
información, sin embargo, siendo SQLite un gestor de bases de datos portable se
considera la aparición de éstas alrededor del año 2000. Otro motivo para elegir este
año es por el surgimiento de las bases de datos móviles, teniendo la mayoría de
éstas como característica la portabilidad.

5.4. Gestores
Gestores de bases de datos como SQLite, Derby, Firebird, Neodatis e Interbase
tienen la capacidad de reunir los archivos necesarios, incluyendo carpetas y librerías
que puedan ser utilizadas durante la ejecución en el equipo terminal donde vaya a
ser utilizada la DB. Existen otros DBSM que tienen la capacidad de crear este tipo
de base de datos, sin embargo, el trabajo del dispositivo final no es tan ligero y
necesita un poco de intervención para su ejecución.

ü SQLite:

En el año 2000 sale la suscripción del código alfa, de allí en adelante empiezan a
añadirse operadores y demás código para su implementación final. La última versión
según la página de SQLite, (2016) fue lanzada el 6 de enero de 2017, versión
3.16.2.

Su principal característica es la movilidad y portabilidad, quizás, es uno de los pocos


gestores de bases de datos que tienen alto porcentaje de invisibilidad de ejecución

31
para el usuario. No necesita un proceso del servidor para iniciar, parar o configurar
algún servicio.

ü Neodatis:

Principalmente es un gestor de bases de datos orientada objetos, se puede


considerar dentro de esta categoría ya que para usuarios de Java su
implementación suele ser muy fácil; sólo se debe de instalar el plugin seleccionado,
sin embargo, se requiere cierto porcentaje de participación del usuario. En la página
de Slashdot Media, (2009) su autor comenta que Neodatis está disponible para
lenguajes como Java, .Net, Google Android, Groovy y Scala.

ü Interbase:

Inicia en el año 2000 con la compañía Borland Software Corporation, al igual que
Firebird en el 2002. Ambos DBSM toman pocos minutos en ejecutarse, tal y como
dice Embarcadero Technologies, (2017), se implementan silenciosamente junto con
la aplicación. InterBase ocupa poco lugar en disco y de memoria. Ideal para
implementar en cualquier dispositivo.

Al ser utilizado en cualquier plataforma se reduce considerablemente su ejecución,


esto con el fin de que los datos sean llamados y modificados fácilmente, logrando
evaluaciones y entregas múltiples sin depender de las acciones del sistema
operativo.

6. Móviles
Una base de datos móvil es una BD que puede ser instalada en un dispositivo de
computación móvil a través de una red móvil. El cliente y el servidor tienen
conexiones inalámbricas. La memoria caché se mantiene para almacenar los datos
frecuentes y transacciones de manera que no se pierdan debido a un fallo de
conexión.

Una base de datos es una forma estructurada de organizar la información. Esto


podría ser una lista de contactos, información de precios o la distancia recorrida.

32
Ejemplo:

Una plantilla de trabajadores con bases de datos móviles. En este escenario el


usuario requeriría poder acceder y actualizar la información de los archivos en los
directorios de inicio de un servidor o cliente de registros de una base de datos. Este
tipo de acceso y carga de trabajo generada por dichos usuarios es diferente de las
cargas de trabajo tradicionales visto en los sistemas cliente servidor de hoy.

Las bases de datos móviles permiten a los empleados introducir datos sobre la
marcha. La información puede ser sincronizada con una base de datos de servidor
posteriormente.

6.1. Sistemas de base de datos móviles


Es necesario además conocer que los SGBDM tienen la habilidad de recuperar la
información de los sistemas de computación y/o repositorios de información sobre
dispositivos móviles en cualquier momento en cualquier lugar; además de introducir
o actualizar información en los sistemas principales de forma remota desde el
dispositivo móvil. Esto da toda la libertad al usuario de manipular toda la información
desde lejos. Es un sistema distribuido que soporta conectividad móvil, posee todas
las capacidades de un sistema de base de datos y permiten a las unidades móviles
una completa movilidad espacial por medio de la tecnología inalámbrica.

El único reto en los SGBDM es el procesamiento de consultas que dependen de la


localización física de la unidad móvil, estas últimas son consultas que involucran la
localización física de la unidad móvil en combinación con otros datos como la
localización de otras unidades móviles o estructuras físicas.

Ejemplo:

Encontrar el hotel más cercano al usuario desde donde éste se encuentre


posicionado, con un precio para él inferior a $50. Para dar respuesta a este tipo de
consulta, se debe poder determinar con exactitud la localización de la unidad móvil
y estar en la capacidad de procesar de manera espacial los datos a consultar, utilizar
la triangulación si el dispositivo se encontrara en múltiples celdas, por localización

33
de celdas, GPS (Global Positioning System) y se tiene que tomar en cuenta que la
unidad puede estar en movimiento mientas se realiza la consulta.

6.2. Características / funcionalidades

Entre las funcionalidades de SGBD móviles se encuentran:

ü Comunicarse con el servidor de base de datos centralizado utilizando la


nueva era de la tecnología de comunicaciones con acceso a Internet.
ü Replicar y sincronizar los datos en el servidor de base de datos centralizado
y en el dispositivo móvil.
ü Capturar los datos que llegan del Internet.
ü Gestionar los datos en el dispositivo móvil.
ü Analizar los datos almacenados en un dispositivo móvil.
ü Crear aplicaciones móviles personalizadas.

6.3. Componentes de una base de datos móvil

ü Servidor de base de datos corporativo y SGBD que gestiona y almacena los


datos corporativos.
ü Base de dato remota y SGBD que gestiona y almacena los datos móviles.
ü Plataforma de base de datos móvil, que puede ser una computadora portátil
o similar con acceso a Internet.
ü Enlaces de comunicaciones bidireccionales entre el SGBD corporativo y el
SGBD móvil.

Algunos aspectos a tener en cuenta a la hora de diseñar e implementar SGBD


móviles, son los siguientes:

ü Desconexión. No hay que olvidar que los terminales móviles están a menudo
desconectados y que esta desconexión no se considera un fallo como en los
sistemas tradicionales, sino que, en todo caso, se podrían ver como “fallos
planificados”.

34
ü Pequeño tamaño y peso de los terminales que, entre otras cosas, hace
necesario buscar protocolos y algoritmos eficientes en “energía”, debido a las
restricciones de baterías que presentan este tipo de equipos. Es
imprescindible también llegar a conseguir un equilibrio entre memoria y disco,
por ejemplo, las técnicas de comprensión permiten ahorrar disco, pero al
descomprimir la información se consume CPU y, por tanto, energía.

6.4. Ventajas y desventajas


Ventajas Desventajas
ü Dependiente de conexión. ü Movilidad de usuarios.
ü Cobertura de red. ü Acceso remoto.
ü Costos de transmisión. ü Costos transporte físico.
ü Estabilidad. ü Mercado potencialmente
ü Consistencia y coherencia de BD. amplio.
ü Fallos complejos propios de entorno ü Gran ámbito de aplicación.
distribuidos.
ü Capacidad de terminales.
Tabla 7. Ventajas y desventajas de bases de datos móviles.

6.5. Evolución
Llegado el siglo XXI y en respuesta a las nuevas necesidades y eficiencia surgen
las Bases de Datos Móviles. Como bien hemos podido observar, en los últimos años
los grandes avances en la tecnología de comunicaciones inalámbricas han dado
origen a dispositivos en forma de ordenadores portátiles o algunos otros dispositivos
con acceso a Internet. Si a esto le unimos la rápida distribución de las
comunicaciones, ya sea de accesos desde teléfonos móviles, conexiones
inalámbricas o vía satélite, podemos tener acceso a todo tipo de información desde
prácticamente cualquier sitio y en cualquier momento.

Esto resulta muy cómodo y ventajoso, ya que en algunos casos el usuario de un


dispositivo móvil puede conectarse a un servidor de base de datos corporativos
gracias a los agentes móviles y trabajar allí con los datos mientras que en otros el
usuario puede descargar los datos y trabajar con ellos en un dispositivo móvil, Es

35
decir, varias aplicaciones pueden tener acceso simultáneo a la información
compartida. Esta característica permite a los usuarios estar en una sincronización
con la base de datos corporativa en diferentes ubicaciones geográficas. Los agentes
móviles son piezas de software dotados con algún grado de inteligencia artificial con
la capacidad de detener su ejecución. Viajan a través de las redes manteniendo
intactos tanto el código como los datos. Los agentes móviles, son capaces de
ejecutarse en varias máquinas.

Por todo esto, podríamos definir una base de datos móvil como una base de datos
portable y físicamente independiente del servidor corporativo de bases de datos,
pero que es capaz de comunicarse con ese servidor desde sitios remotos,
permitiéndose el compartir datos corporativos.

6.6. Gestores
ü Pointbase:

PointBase Inc. Comienza su operación en 1998 con desarrollo de SGBDs dirigidas


a dispositivos móviles, la compañía fue vendida y no fue hasta 2007 cuando IBM la
adquiere, después de esto, surge la evolución de las bases de datos de fijas a
móviles, hasta hoy en día su versión más reciente de un manejador de bases de
datos relaciona muy pequeña con un soporte de SQL con optimizaciones.

ü SQLAnywhere:

Base de datos móvil relacional con proveedor de tecnología para el intercambio y


gestión de datos desde un dispositivo móvil, diseñado para dispositivos con
plataforma Windows Mobile 5 para Pocket PC y Smartphone, y Windows Mobile,
con una arquitectura de tipo Cliente - Servidor, permiten conexiones simultáneas,
también permite la sincronización entre sistemas fijos y usuarios móviles.

ü DB2 EveryPlace:

Desarrollado por IBM, es una base de datos móvil con un alto rendimiento, la cual
permite la ampliación de los datos y aplicaciones a dispositivos móviles como
agentes digitales, personales y teléfonos inteligentes, una de sus desventajas es el

36
reducido espacio que tiene y solo se integra con la gama de dispositivos IBM. Esta
base de datos es relacional con arquitectura Cliente - Servidor.

ü Oracle Lite:

Sistema gestor de base de datos móvil que trabaja con arquitectura Cliente -
Servidor, en donde son optimizados para dispositivos de mano, portátiles, estos
tienen un soporte multiusuarios, funciona sobre plataformas Windows Mobile,
PocketPC, Symbian OS, y Linux, algunas de sus ventajas son el permitir el
despliegue de información sin conexión, ofrece métodos de administración y
sincronización de dispositivos, además de una base de datos relacional segura,
ligera y compatible con SQL.

ü MSSQL CE:

En sus inicios surgen una serie de cambios y versiones, llegando a SQL SERVER
2005 Mobile, dirigida a Smarphones y PDAs, la cual es una versión compacta que
presenta una gran variedad de funciones y con un diseño para una admisión de
grandes listas de dispositivos inteligentes y Tablets, esta cuenta con un motor de
base de datos compacto y un optimizador de consultas sólido, también permite
acceso a datos remotos, su arquitectura está formada por un entorno de desarrollo,
un cliente y el servidor, a diferencia de la nueva versión del manejador, que utiliza
una arquitectura embebida.

ü SQLite:

Herramienta de software libre, que permite almacenar información en dispositivos


instalados de forma sencilla, eficaz, rápida y en equipos con pocas capacidades de
hardware, como puede ser una PDA o un teléfono celular, soporta las consultas más
básicas y las más complejas del lenguaje SQL, uno de los aspectos importantes de
este gestor es que se puede usar en dispositivos móviles y sistemas de escritorio.

37
Figura 13 Tabla comparativa de algunos sistemas gestores de bases de datos. Delgado, P. &
Gama, L. (2017).

Diagrama evolutivo

Figura 14 Evolución de las bases de datos.

38
Tabla comparativa
Base de datos Distribuidas Paralelas Cliente - Federadas Móviles Portables
servidor
Año 1980 1980 1990 1990 2000 2000
Características Son Divide grandes El servidor Se Es instalada en Tiene la
fragmentos tareas en presta a todos interrelacionan un dispositivo capacidad de ser
que se muchas tareas sus clientes una múltiples de computación ejecutadas en
encuentran más pequeñas y interfaz única y gestores de móvil a través diferentes
almacenados las distribuye bien definida, bases de datos de una red plataformas con
en lugares entre además, el mediante un móvil, en donde pocas
distintos, es computadoras cliente no servidor el cliente y el modificaciones.
decir, tienen interconectadas. depende de la federado que servidor tienen
autonomía ubicación física realiza la conexiones
local. del servidor, del interpretación inalámbricas.
tipo de equipo, ni de las consultas
del SO. entre los
mismos.
Ventajas La probabilidad Puede mejorar Es más factible Permite La movilidad El usuario final
de que el el rendimiento que el sistema conectar del usuario es tiene muy poca o
sistema esté mediante sea escalable. diferentes mayor, al no nula
listo y gestores de tener

39
funcionando escalamiento y bases de datos dependencia de participación en
continuamente aceleración. para conformar un PC. la ejecución.
a lo largo de un una sola BD.
período
especificado.
Desventajas Costo y Implica grandes Los problemas Solo son El costo de Al ser diseñadas
complejidad costos en de saturación en accesibles transmisión es para móviles su
del software, software de la red pueden desde equipos alto para hacer almacenamiento,
dado que se DBMS y bajar el fijos respaldo y nivel de
requiere un software de rendimiento por conectados en conexiones a seguridad y de
software más coordinación debajo de lo que la BD alojadas en conexión con
complejo para especializado. se tendría con infraestructura otro dispositivo. demás BD es
ambientes una sola del sistema de muy poco.
distribuidos. máquina. base de datos.
Tabla 8. Tabla comparativa de tipos de bases de datos.

40
Bibliografía
Bases de datos avanzadas (2016). Bases de datos móviles. Retrieved 16 January
2017, from https://basesdedatosavanzadas.wikispaces.com/Moviles
Date, C. J. (2001). Introducción a los sistemas de bases de datos 7ª Ed., Pearson
Educación, México.
Delgado, P., & Gama, L., Evolución de las Bases de Datos: de Fijas a Móviles. La
computadora, herramienta indispensable en diversas áreas de conocimiento,
277.
Embarcadero Technologies, I. (2017). InterBase - Embeddable Database |
Embarcadero. Retrieved January 16, 2017, from
https://www.embarcadero.com/products/interbase/
Filein Rómel, SQLite: La Base de Datos Embebida (2015). Retrieved 16 January
2017, from http://sg.com.mx/revista/17/sqlite-la-base-datosembebida
Hernández, D. D. L. C. R., Vázquez, R. P., & Labrada, J. V. (2013). Bases De Datos
Móviles. Tlatemoani, (14).
Hernández Orallo, J. (2002). La disciplina de los sistemas de bases de datos.
Historia, situación actual y perspectivas. Departamento de Sistemas Informátics
i Computació, Universitat Politécnica de Valencia.
Mannino, M. V. (2007). Administración de base de datos. McGraw-Hill
Interamericana.
Mendoza Gonzalez, N. (2010). Arquitectura cliente servidor. Slideshare, 36.
Retrieved from http://es.slideshare.net/NoeGonzalezMendoza/arquitectura-
cliente-servidor.
Mendoza, L. E. (n.d.). Sistemas de Información II - Teoría. Sistemas de Información
II - Teoría.
Pech, F. (2012). Bases de Datos Distribuidas – Panorama General (diapositivas de
PowerPoint)
Ramirez, T. A. (2014). Bases de datos federadas. Retrieved January 16, 2017, from
http://www.tonahtiu.com/notas/BD/BDF.htm
Rivero, E. (2004). Bases de Datos Relacionales: Diseño Físico (orientado al DB2
para z/Os de IBM), Universidad Pontifica Comillas, Madrid.
Silberschatz, A. (Bell L., Korth, H. F. (Bell L., & Sudarshan, S. (Instituto Indio de
Tecnología, B. (2002). Fundamentos de bases de datos. Victoria.
https://doi.org/10.1017/CBO9781107415324.004
Slashdot Media. (2009). NeoDatis ODB / News. Retrieved January 16, 2017, from

41
https://sourceforge.net/p/neodatis-odb/news/
SQLite. (2016). Alphabetical List Of SQLite Documents. Retrieved January 16, 2017,
from https://www.sqlite.org/doclist.html
Valencia, J. F. (2016). DATA : Base de datos portable y multimedia para Google
Drive, OneDrive, Dropbox, memoria USB/SD. Retrieved January 16, 2017, from
http://www.mipropiosoft.com/data/

42

También podría gustarte