UNIVERSIDAD CATÓLICA DE CUENCA FACULTAD DE

INGENIERIA DE SISTEMAS

MATERIA:
ESTRUCTURA Y BASE DE DATOS

NOMBRES:
CARLOS NÁJERA
EDYSON GUARACA

PROFESORA:
ING. CATHERINE CABRERA

CURSO:
TERCERO DE SISTEMAS

TEMA:
ARQUITECTURA DE LOS SISTEMAS DE BASES DE DATOS

AÑO LECTIVO
2013 -2014
 INTRODUCCION
En el presente ensayo se realizara una investigación sobre la arquitectura de los sistemas de
las bases de datos. En él abordaremos varias arquitecturas como Sistemas de bases de datos
cliente-servidor, Arquitectura Centralizada, Control de concurrencia en las Bases de datos
distribuidas, entre otros.

ARQUITECTURAS DE SISTEMAS DE BASES DE DATOS

La arquitectura de un sistema de base de datos está influenciada en gran medida por el
sistema informático subyacente en el que se ejecuta el sistema de base de datos. En la
arquitectura de un sistema de base de datos se reflejan aspectos como la conexión en red, el
paralelismo y la distribución.

La arquitectura ANSI/SPARC.

El objetivo principal de la arquitectura ANSI/SPARC es definir un SGBD con el máximo grado

de independencia, separando las aplicaciones de usuario y la base de datos física. Para ello se
utilizan tres niveles de abstracción conocidos como interno, conceptual y externo.

1. El nivel interno es el más cercano a la máquina. Es una representación a bajo nivel de la BD

se compone de varias ocurrencias de varios tipos de registro interno. En la que se define la
forma en la que los datos se almacenan físicamente en la máquina. Se definen características
como los dispositivos en donde se almacenan los datos, el espacio que se reserva, las
estrategias de acceso, la creación de ficheros de índices, etc. Utiliza ANSI/SPARC para
referirse a la construcción que hemos estado llamando registro almacenado.

2. El nivel conceptual describe la estructura de los datos que van a ser almacenados en la base
de datos, esconde los detalles del almacenamiento físico y se concentra en describir entidades,
tipos de datos, relaciones, operaciones de usuario y restricciones. El nivel conceptual es un
nivel de mediación entre el nivel interno y externo. La vista conceptual es una representación
de toda la información contenida en la base de datos.

3. El nivel externo o nivel de vista incluye varios esquemas externos o vistas de usuario. Cada
esquema externo describe la parte de la base de datos en la que está interesado un grupo de
usuarios en particular y esconde el resto de la base de datos para esos usuarios. El nivel
externo es el más cercano a los usuarios, es decir, es el que se ocupa de la forma en la que los
usuarios perciben los datos.
 ARQUITECTURA CENTRALIZADA

Los sistemas de bases de datos centralizadas son aquellos que se ejecutan en un único
sistema informático sin interactuar con ninguna otra computadora. Tales sistemas van desde
los sistemas de bases de datos mono usuarios ejecutándose en computadoras personales
hasta los sistemas de bases de datos de alto rendimiento encuitándose en grandes sistemas.

Características de las bases de datos centralizadas:

 Se almacena completamente en una localidad central.

 No posee múltiples elementos de procesamiento ni mecanismos de intercomunicación
como las bases de datos distribuidas.
 Los componentes de las bases de datos centralizadas son: los datos, el software de
gestión de bases de datos y los dispositivos de almacenamiento secundario asociados.
 El problema de seguridad es fácil de manejar en estos sistemas de bases de datos.

Ventajas de las bases de datos centralizadas.-

 Se evita la redundancia.
 Se evita la inconsistencia.
 Pueden aplicarse restricciones de seguridad.
 Puede conservarse la integridad.
 El procesamiento de los datos ofrece un mejor rendimiento y resulta más confiable que
los sistemas distribuidos.

Desventajas de las bases de datos centralizadas:

 Si el sistema de base de datos falla, se pierde la disponibilidad y procesamiento de la

información que posee el sistema.
 Difícil sincronización para su recuperación.
 Las cargas de trabajo no se pueden difundir entre varias computadoras.

ARQUITECTURA CLIENTE/SERVIDOR

Un servidor es una aplicación que ofrece un servicio a los usuarios de Internet; un cliente es el
que solicita ese servicio.

La arquitectura 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 diálogo o solicita los recursos y servidor, al
proceso que responde a las solicitudes. Es el modelo de interacción más común entre
aplicaciones en una.red.

Este tipo de arquitectura es la más utilizada en la actualidad, debido a que es la más avanzada
y la que mejor ha evolucionado en estos últimos años.

Podemos decir que esta arquitectura necesita tres tipos de software para su correcto
funcionamiento:

Software de gestión de datos: Este software se encarga de la manipulación y gestión de los

datos almacenados y requeridos por las diferentes aplicaciones. Normalmente este software se
aloja en el servidor.

Software de desarrollo: este tipo de software se aloja en los clientes y solo en aquellos que se
dedique al desarrollo de aplicaciones.

Software de interacción con los usuarios: También reside en los clientes y es la aplicación
gráfica de usuario para la manipulación de datos, siempre claro a nivel usuario (consultas
principalmente).

VENTAJAS:

1.- Mejor aprovechamiento de la potencia de cómputo (Reparte el trabajo).

2. -Reduce el tráfico en la Red. (Viajan requerimientos).

3.- Opera bajo sistemas abiertos.

4.- Permite el uso de interfaces gráficas variadas y versátiles.

PARTES DE UN SISTEMA CLIENTE/SERVIDOR:

Los principales componentes de un sistema cliente/servidor son:

- El núcleo (back-end o sección posterior). Es el SGBD propiamente (servidor).

- El interfaz (front-end o sección frontal). Aplicaciones que funcionan sobre el SGBD (cliente).

PARALELISMO E/S
El paralelismo de E/S es cuando hablamos de divisiones en las relaciones entre varios discos
para reducir el tiempo necesario de su recuperación.

Normalmente la división más común en un entorno de bases de datos paralelas es la división

horizontal. En este tipo de división las tuplas de cada relación se dividen entre varios discos de
modo que cada tupla resida en un disco distinto. Suponiendo que tenemos n discos (D0,D1,
…,Dn) entre los que se van a dividir los datos, existen varias estrategias de división:

Turno rotatorio: Se recorre la relación y la i-ésima tupla se envía al disco Di quedando una
distribución homogénea de las tuplas en los discos.

División por asociación: Se escogen varios atributos del esquema de la relación y se

designan como atributos de división. Se escoge una función de asociación cuyo rango es {0,1,
…,n-1}. Cada tupla de la relación original se asocia en términos de los atributos de división. Si
la función de asociación devuelve i, la tupla de ubica en el disco DI.

División por rangos: Se distribuye rangos contiguos de valores de los atributos a cada disco.

PARALELISMO ENTRE CONSULTAS

Los sistemas de bases de datos con arquitectura paralela deben asegurarse de que dos
procesadores no actualicen simultáneamente los mismos datos de manera independiente.

Cuando un procesador accede a los datos o los actualiza, el sistema de bases de datos debe
garantizar que tenga su última versión en la memoria intermedia. El problema de asegurar que
la versión sea la última disponible se denomina problema de coherencia de cache.

Existen una serie de protocolos para garantizar la coherencia de cache, que normalmente se
integran con los de control de concurrencia para reducir la sobrecarga.

Los protocolos de este tipo de sistemas de disco compartido son los siguientes:

 Antes de cualquier acceso de lectura o escritura de una página, la transacción la

bloquea en modo compartido o excluso, según corresponda. Inmediatamente después
de obtener el bloqueo compartido o exclusivo de la página, la transacción lee también
su copia más reciente del disco compartido.
 Antes de que una transacción libere el bloqueo exclusivo de una página, la traslada al
disco compartido, posteriormente libera el bloqueo.

Con este protocolo se garantiza que cuando una transacción establece un bloqueo compartido
o exclusivo sobre una página, obtenga la copia correcta de la página.

PARALELISMO EN CONSULTAS
Es la ejecución en paralelo de una única consulta entre varios procesadores y discos, cuyo
objetivo es acelerar las consultas de ejecución prologada. Por tanto se puede hacer paralelas
las consultas haciendo paralelas las operaciones que las forman. Existen dos maneras de
ejecutar en paralelo una sola consulta:

1. Paralelismo en operaciones. Se puede acelerar el procesamiento de las consulta

haciendo paralela la ejecución de cada una de sus operaciones individuales
ordenación, selección, proyección y reunión.
2. Paralelismo entre Operaciones. Se puede acelerar el procesamiento de la consulta
ejecutando en paralelo las diferentes operaciones de las expresiones de las consultas.

Por lo tanto el objetivo que se persigue es dividir la relación que interviene en la consulta por
medio de técnicas de división de relaciones, guardar dichas relaciones en discos que van a ser
gestionados cada uno de ellos por un procesador, a su vez, cada procesador ejecuta su
consulta local y cada uno de estos resultados parciales se unen para formar la respuesta a la
consulta.

DISEÑO DE SISTEMAS PARALELOS

Varias unidades de almacenamiento de datos y procesadores operan en paralelo para

incrementar el rendimiento.

Solución al problema de transacciones masivas

Paralelismo a nivel de disco (I/O) y de procesador

Medidas del rendimiento en:

Productividad (Throughput): #Tareas/U.Tiempo

Tiempo de Respuesta: ∆T para una tarea

Niveles de Paralelismo:

Grano Grueso: Cada transacción en un procesador diferente.

Grano Fino: Las operaciones de cada transacción se pueden distribuir en varios

procesadores

Ganancia o escalamiento:
Velocidad: A mayor sea la cantidad de recursos, mayor es la velocidad del sistema

Ampliabilidad: Tareas más largas en menos tiempo. Puede ser medida en:
 Lotes: Base de datos mas grande (mayor numero de registros), las
transacciones duran más tiempo.

Transacciones: Aumenta el número de transacciones que llegan a la base

de datos y crece el tamaño de la misma.

Inconvenientes con el paralelismo

Costo de Inicio: Tiempo para iniciar un proceso.

Interferencia: Cuellos de botella para acceder a los recursos compartidos

Sesgo: La partición de las tareas en procesos paralelos no siempre es uniforme

Comunicación a través de escrituras en memoria

Limite del numero de procesadores por el canal de comunicación

Acceso paralelo
 ALMACENAMIENTO DISTRIBUIDO DE DATOS

Para este punto, consideraremos una tabla T que se tiene que almacenar el una base de datos
distribuida. Existen varias opciones:

Réplica: El sistema conserva varias copias o réplicas idénticas de la tabla. Cada réplica se
almacena en un nodo diferente, lo que da lugar a redundancia de datos. La alternativa a la
réplica es guardar la tabla en un solo nodo. La réplica presenta las siguientes ventajas e
inconvenientes:

Disponibilidad: Como se vio en la introducción, la réplica permite que el sistema siga

funcionando aún en caso de caída de uno de los nodos.

Aumento del paralelismo: En el caso de que la mayoría de los accesos a la tabla T sean de
lectura, varios nodos pueden realizar consultas en paralelo sobre la misma tabla. Cuantas más
réplicas existan de la tabla, mayor será la posibilidad de que el dato buscado se encuentre en
el nodo desde el que se realiza la consulta, minimizando con ello el tráfico de datos entre
nodos.

Aumento de la sobrecarga en las actualizaciones: El sistema debe asegurar que todas las
réplicas de la tabla sean consistentes, por tanto, cuando se realiza una actualización sobre una
de las réplicas, los cambios deben propagarse a todas las réplicas de dicha tabla a lo largo del
sistema distribuido. Esto hace que las actualizaciones sean más costosas que en los sistemas
centralizados. En general, el sistema de réplica hace que las consultas sean más eficientes,
pero complica las actualizaciones debido al problema de la redundancia de datos y el
mantenimiento de la consistencia.

TRANSACCIONES DISTRIBUIDAS

Las transacciones distribuidas abarcan dos o más servidores conocidos como administradores
de recursos. La administración de la transacción debe ser coordinada entre los administradores
de recursos mediante un componente de servidor llamado administrador de transacciones.
Cada instancia de SQL Server Database Engine (Motor de base de datos de SQL Server)
puede funcionar como administrador de recursos en las transacciones distribuidas que
coordinan los administradores de transacciones, como el Coordinador de transacciones
distribuidas de Microsoft (MS DTC) u otros administradores que admitan la especificación Open
Group XA del procesamiento de transacciones distribuidas.

En la aplicación, una transacción distribuida se administra de forma muy parecida a una

transacción local. Al final de la transacción, la aplicación pide que se confirme o se revierta la
transacción. El administrador de transacciones debe administrar una confirmación distribuida
de forma diferente para reducir al mínimo el riesgo de que, si se produce un error en la red,
algunos administradores de recursos realicen confirmaciones mientras los demás revierten la
transacción. Esto se consigue mediante la administración del proceso de confirmación en dos
fases (la fase de preparación y la fase de confirmación), que se conoce como confirmación en
dos fases (2PC).

Fase de preparación
Cuando el administrador de transacciones recibe una solicitud de confirmación, envía
un comando de preparación a todos los administradores de recursos implicados en la
transacción. Cada administrador de recursos hace lo necesario para que la transacción
sea duradera y todos los búferes que contienen imágenes del registro de la transacción
se pasan a disco. A medida que cada administrador de recursos completa la fase de
preparación, notifica si la preparación ha tenido éxito o no al administrador de
transacciones.

Fase de confirmación
Si el administrador de transacciones recibe la notificación de que todas las
preparaciones son correctas por parte de todos los administradores de recursos, envía
comandos de confirmación a cada administrador de recursos. A continuación, los
administradores de recursos pueden completar la confirmación. Si todos los
administradores de recursos indican que la confirmación ha sido correcta, el
administrador de transacciones envía una notificación de éxito a la aplicación. Si algún
administrador de recursos informó de un error al realizar la preparación, el
administrador de transacciones envía un comando para revertir la transacción a cada
administrador de recursos e indica a la aplicación que se ha producido un error de
confirmación.

CONTROL DE CONCURRENCIA

El control de transacciones concurrentes en una base de datos brinda un eficiente desempeño

del Sistema de Administración de Base de Datos, puesto que permite controlar la ejecución de
transacciones que operan en paralelo, accediendo a información compartida y, por lo tanto,
interfiriendo potencialmente unas con otras.

El objetivo de los métodos de control de concurrencia es garantizar la no inferencia o la

propiedad de aislamiento de transacciones que se ejecutan de manera concurrente. Los
distintos objetivos atacan el problema garantizando que las transacciones se ejecuten en un
plan que sea serializable, es decir, que el resultado sea equivalente a el resultante de ejecutar
un plan en serie.

DISPONIBILIDAD
Generalmente la disponibilidad se refiere al porcentaje de tiempo de un sistema o aplicación la
cual está funcionando correctamente. Ésta definición es muy simple porque la alta
disponibilidad tiene en cuenta criterios como duración, frecuencia o el impacto cuando algo
falla. El objetivo general de la alta disponibilidad es hacer un sistema tolerantes a fallas. Para
medir la disponibilidad lo hacemos en 3 componentes generales:

1. El número de fallas y de mantenimientos que ocurren en un sistema en un periodo de

tiempo.

2. La robustez: es el grado de protección de un sistema o aplicación ante un evento de falla del

sistema, permitiéndole continuar disponible cuando se presenta la falla.

3. La recuperación: es la velocidad en tiempo que se demora un sistema o aplicación para

retornar a su estado normal después de que a ocurrido un fallo.

PROCESAMIENTO DE CONSULTAS

El procesamiento de consultas es de suma importancia en bases de datos centralizadas. Sin

embargo, en BDD éste adquiere una relevancia mayor.

El objetivo es convertir transacciones de usuario en instrucciones para manipulación de datos.

No obstante, el orden en que se realizan las transacciones afecta grandemente la velocidad de
respuesta del sistema. Así, el procesamiento de consultas presenta un problema de
optimización en el cual se determina el orden en el cual se hace la menor cantidad de
operaciones

Metodología Procesamiento Consultas Distribuidas:

Primeramente se debe de contar con heterogenidad de los datos, para que puedan ser usados
para formular consultas. Tenemos los siguientes ejemplos:

bd centralizada
bd distruibuida

ESTRATEGIAS DE PROCESAMIENTO DE CONSULTAS DE BASES DE DATOS

DISTRIBUIDAS

Contamos con la estrategia de Reformulación de consultas, que nos sirve para encontrar q la
información que nos va a proveer sea solo la que se le pidió por la fuente

También se cuenta con la estrategia de descomposición de las fuentes, q consiste en que

según las fuentes q pidan cierto tipo de datos sean las atenidas con mayor velocidad.

CONCLUSIONES

Lo bueno es la Disponibilidad frente a fallos de la red en el paralelismo, las peticiones

se pueden procesar en varios nodos en paralelo y la transferencia de datos reducida

Lo malo se eleva el coste de las actualizaciones y se complica el control de la

concurrencia

BIBLIOGRAFIA

http://normalizacion-bd.blogspot.com/2012/11/5-arquitectura-centralizada.html

http://unefazuliasistemas.files.wordpress.com/2011/04/fundamentos-de-bases-de-
datos-silberschatz-korth-sudarshan.pdf

http://univirtual.unicauca.edu.co/moodle/pluginfile.php/18660/mod_resource/content/
0/Materiales/clase_10/03-

http://delaoarrieta.blogspot.com/2012/10/diferentes-estrategias-de-procesamiento.html

http://tadebasegino.blogspot.com/2012/11/arquitectura-clienteservidor.html