UNIDAD1

1.1Arquitectura
Componentes
Hardware involucrado
El hardware utilizado no difiere mucho del hardware utilizado en un servidor normal. Al principio se creía que si los componentes de una base de datos eran especializados serían más eficientes y rápidos, pero se comprobó que el decentralizar todo y adoptar un enfoque "nada compartido" (shared-nothing) resultaba más barato y eficaz. Por lo que el hardware que compone una base de datos distribuida se reduce a servidores y la red.
Software
Sistema de Administración de Base de Datos Distribuida (DDBMS)
Este sistema está formado por las transacciones y los administradores de la base de datos distribuidos. Un DDBMS implica un conjunto de programas que operan en diversas computadoras, estos programas pueden ser subsistemas de un único DDBMS de un fabricante o podría consistir de una colección de programas de diferentes fuentes.
Administrador de transacciones distribuidas (DTM)
Este es un programa que recibe las solicitudes de procesamiento de los programas de consulta o transacciones y las traduce en acciones para los administradores de la base de datos. Los DTM se encargan de coordinar y controlar estas acciones. Este DTM puede ser propietario o desarrollado en casa.
Administrador de la base de datos (DBM)
Es un programa que procesa cierta porción de la base de datos distribuida. Se encarga de recuperar y actualizar datos del usuario y generales de acuerdo con los comandos recibidos de los DTM.
Nodo
Un nodo es una computadora que ejecuta un DTM o un DBM o ambos. Un nodo de transacción ejecuta un DTM y un nodo de base de datos ejecuta un DBM.





1.1.1Autonomía
1. Autonomía. La autonomía se puede presentar a diferentes niveles:
• Autonomía de diseño. La habilidad de un componente del SMBD para decidir cuestiones relacionadas a su propio diseño.
• Autonomía de comunicación. La habilidad de un componente del SMBD para decidir como y cuando comunicarse con otros SMBD.
• Autonomía de ejecución. La habilidad de un componente del SMBD para ejecutar operaciones locales de la manera que él quiera.

1.1.2Heterogeneidad
Heterogeneidad. La heterogeneidad se puede presentar a varios niveles: hardware, sistema de comunicaciones, sistema operativo o SMBD. Para el caso de SMBD heterogéneos ésta se puede presentar debido al modelo de datos, al lenguaje de consultas o a los algoritmos para manejo de transacciones.
Esta clase se caracteriza por el uso de diferentes DBMS
en los nodos locales. Hay dos subclases principales: los que hacen su integración
totalmente dentro del sistema, y los más simples “hooks” o los apéndices externos
llamados gateways, para permitir enlace a sistemas ajenos.
La anterior subclase puede ser adicionalmente refinada en una subclase que
provee un subconjunto importante de funciones que uno esperaría desde cualquier
SGBD, y que enfatiza en los aspectos más pragmáticos del manejo de datos
colectivos , tales como conversiones entre sistemas y algún aspecto básico de
desempeño(sistemas multidatabase). Los sistemas multidatabase (SGBDMs)
tienen múltiples SGBD, posiblemente de diferentes tipos, y múltiples, DBs
preexistentes. La integración es desempeñada por lo tanto por múltiples software
de subsistemas.


1.1.3Distribución y esquema global
Distribución de los datos
Una de las decisiones más importantes que el diseñador de bases de datos distribuidas debe tomar es el posicionamiento de la data en el sistema y el esquema bajo el cuál lo desea hacer. Para esto existen cuatro alternativas principales: centralizada, replicada, fragmentada, e híbrida. La forma centralizada es muy similar al modelo de 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 de los datos no se gana nada.
Replicadas
El esquema de BDD de replicación consiste en que cada nodo debe tener su copia completa de la base de datos. Es fácil ver que este esquema tiene un alto costo en el almacenamiento de la información. Debido a que la actualización de los datos debe ser realizada en todas las copias, también tiene un alto costo de escritura, pero todo esto vale la pena si tenemos un sistema en el que se va a escribir pocas veces y leer muchas, y dónde la disponibilidad y fiabilidad de los datos sea de máxima importancia.
Particionadas
Este modelo consiste en que solo hay una copia de cada elemento, pero la información está distribuida a través de los nodos. En cada nodo se aloja uno o más fragmentos disjuntos de la base de datos. Como los fragmentos no se replican esto disminuye el costo de almacenamiento, pero también sacrifica la disponibilidad y fiabilidad de los datos. Algo que se debe tomar en cuenta cuando se desea implementar este modelo es la granularidad de la fragmentación. La fragmentación se puede realizar también de tres formas:
• Horizontal: Los fragmentos son subconjuntos de una tabla (análogo a un restringir)
• Vertical: Los fragmentos son subconjuntos de los atributos con sus valores (análogo a un proyectar)
• Mixto: Se almacenan fragmentos producto de restringir y proyectar una tabla.
Una ventaja significativa de este esquema es que las consultas (SQL) también se fragmentan por lo que su procesamiento es en paralelo y más eficiente, pero también se sacrifica con casos especiales como usar JUNTAR o PRODUCTO, en general casos que involucren varios fragmentos de la BDD.
Para que una fragmentación sea correcta esta debe cumplir con las siguientes reglas:
• Debe ser Completa: Si una relación R se fragmenta en R1,R2, ... , Rn, cada elemento de la data de R debe estar en algún Ri.
• Debe ser Reconstruible: Debe ser posible definir una operación relacional que a partir de los fragmentos obtenga la relación.
• Los fragmentos deben ser Disjuntos: Si la fragmentación es horizontal entonces si un elemento e está en Ri este elemento no puede estar en ningún Rk (para k distinto a i). En el caso de fragmentación vertical es necesario que se repitan las llaves primarias y esta condición solo se debe cumplir para el conjunto de atributos que no son llave primaria.
Híbrida
Este esquema simplemente 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 del sistema de BDD.
Criterios para escoger la distribución
• Localidad de la data: la data debería ser colocada donde ésta se accede más seguido. El diseñador debe analizar las aplicaciones y determinar como colocar la data de tal forma que se optimicen los accesos a la data locales.
• Fiabilidad de la data: Almacenando varias copias de la data en lugares geográficamente apartados se logra maximizar la probabilidad de que la data va a ser recuperable en caso de que ocurra daño físico en cualquier sitio.
• Disponibilidad de la data: como en la fiabilidad, almacenar varias copias asegura que los usuarios tengan a su disponibilidad los elementos de la data, aún si el nodo al que usualmente acceden no está disponible o falla.
• Capacidades y costos de almacenamiento: a pesar de que los costos de almacenamiento no son tan grandes como los de transmisión, los nodos pueden tener diferentes capacidades de almacenamiento y procesamiento. Esto se debe analizar cuidadosamente para determinar donde poner la data. El costo de almacenamiento se disminuye significativamente minimizando la cantidad de copias de la data.
• Distribución de la carga de procesamiento: una de las razones por la cual se escoge un sistema de BDD es porque se desea poder distribuir la carga de procesamiento para hacer este más eficiente.
• Costo de comunicación: el diseñador debe considerar también el costo de usar las comunicaciones de la red para obtener data. Los costos de comunicación se minimizan cuando cada sitio tiene su propia copia de la data, por otro lado cuando la data es actualizada se debe actualizar en todos los nodos.
• Uso del sistema: debe tomarse en consideración cual será el tipo principal de uso del sistema de BDD. Factores como la importancia en la disponibilidad de la data, la velocidad de escritura y la capacidad de recuperación de daños físicos deben tomarse en cuenta para escoger el esquema correcto.
Seguridad
Desde hace ya varios años las bases de datos son ampliamente utilizadas en departamentos de gobiernos, empresas comerciales, bancos, hospitales, etc. Actualmente se está cambiando el esquema bajo el cuál se utilizan las bases de datos, ya no son utilizadas únicamente de forma interna, sino que se tiene muchos accesos externos de tipos distintos. Estos cambios que se han introducido en el uso de las bases de datos ha creado la necesidad mejorar las prácticas de seguridad ya que el ambiente ya no es tan controlado como el esquema antiguo.
Conceptos
Los problemas de mayor importancia en seguridad son autenticación, identificación, y refuerzo de los controles de acceso apropiados. El sistema de seguridad de niveles múltiples. Éste consiste en muchos usuarios con distintos niveles de permisos para una misma base de datos con información de distintos niveles. En las bases de datos distribuidas se han investigado dos acercamientos a este modelo: data distribuida y control centralizado, y data y control distribuidos.
En el acercamiento de data distribuida y control centralizado se divide en dos soluciones: particionado y replicado. En el primero de estos lo que se tiene es un conjunto de nodos y cada uno de ellos opera a cierto nivel de seguridad, así el usuario con nivel de permisos X accede al servidor que maneja la data para X. El replicado surgió debido a que si alguien con altos derechos de seguridad deseaba consultar data con de bajo nivel de seguridad debía enviar su petición a un servidor de bajo nivel de seguridad por lo cual se podría divulgar información sensible. En el esquema replicado entonces la data se repite en cascada de tal forma que el nivel más alto tiene una copia entera de la base de datos, y el más bajo solamente la información de más bajo nivel. El otro acercamiento de data y control distribuido cada nodo contiene información de distintos niveles y está diseñado para aceptar peticiones de cualquier nivel de usuario.

1.2Diseño de bases de datos distribuidas

Cuando pensamos en el diseño de las bases de datos distribuidas debemos tener
en cuenta la ubicación de los programas que accederán a las bases de datos y
sobre los propios datos que constituyen la base de datos, en diferentes puntos de
una red. Sobre la ubicación de los programas supondremos que tenemos una
copia de ellos en cada maquina donde se necesite acceder a la base de datos. Sin
embargo el problema radica en como ubicaremos los datos en la red, existen
diferentes formas de repartir los datos: En solo una maquina que almacene todos
los datos y se encargue de responder a todas las consultas del resto de la red
(sistema centralizado), ubicaríamos la base de dato en cada







1.2.1Diseño top-down : fragmentación.

Un esquema de este proceso puede observarse en la siguiente figura:

1.2.2Diseño bottom-up : integración de bases de datos.
El diseño de abajo hacia arriba (bottom-up). Se utiliza particularmente a partir de bases de datos existentes, generando con esto bases de datos distribuidas. En forma resumida, el diseño bottom-up de una base de datos distribuida requiere de la selección de un modelo de bases de datos común para describir el esquema global de la base de datos. Esto se debe es posible que se utilicen diferentes SMBD. Después se hace la traducción de cada esquema local en el modelo de datos común y finalmente se hace la integración del esquema local en un esquema global común.



1.3 Arquitecturas Cliente/Servidor para SGBD

Esta arquitectura se divide en dos partes claramente diferenciadas, la primera es la parte del servidor y la segunda la de un conjunto de clientes.

Normalmente el servidor es una máquina bastante potente que actúa de depósito de datos y funciona como un sistema gestor de base de datos (SGBD).

Por otro lado los clientes suelen ser estaciones de trabajo que solicitan varios servicios al servidor.

Ambas partes deben estar conectadas entre sí mediante una red.
Una representación gráfica de este tipo de arquitectura sería la siguiente.


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).
A parte de estos existen más aplicaciones software para el correcto funcionamiento de esta arquitectura pero ya están condicionados por el tipo de sistema operativo instalado, el tipo de red en la que se encuentra, etc.


1.3.1Filosofía Cliente/Servido
La tecnología llamada Cliente /Servidor es actualmente utilizada en casi todas las aplicaciones administrativas e Internet/Intranet. Bajo esta filosofia, un servidor es un ordenador remoto, en algún lugar de una red, que proporciona información según se le solicite. Mientras que un cliente funciona en su computadora local, se comunica con el servidor remoto y pide a éste información.
Típicamente, un único servidor atiende a una multitud de clientes, ahorrando a cada uno de ellos el problema de tener la información instalada y almacenada localmente. Los sistemas Cliente-Servidor pueden ser de muchos tipos, pues esto depende principalmente de las aplicaciones instaladas en el propio servidor. Entre otros, existen: servidores de impresión mediante los cuales los usuarios comparten impresoras, servidores de archivos con los que los clientes comparten discos duros, servidores de bases de datos donde existe una única base de datos que es consultada por los clientes y puede o no ser modificada por ellos y servidores Web que utilizan también la tecnología Cliente/Servidor, aunque añaden aspectos nuevos y propios a la misma.



1.3.2Sockets
Para que dos programas puedan comunicarse entre sí es necesario que se cumplan ciertos requisitos:
• Que un programa sea capaz de localizar al otro.
• Que ambos programas sean capaces de intercambiarse cualquier secuencia de octetos, es decir, datos relevantes a su finalidad.
Para ello son necesarios los tres recursos que originan el concepto de socket:
• Un protocolo de comunicaciones, que permite el intercambio de octetos.
• Una dirección del Protocolo de Red (Dirección IP, si se utiliza el Protocolo TCP/IP), que identifica una computadora.
• Un número de puerto, que identifica a un programa dentro de una computadora.
Los sockets permiten implementar una arquitectura cliente-servidor. La comunicación ha de ser iniciada por uno de los programas que se denomina programa cliente. El segundo programa espera a que otro inicie la comunicación, por este motivo se denomina programa servidor.
Un socket es un fichero existente en la máquina cliente y en la máquina servidora, que sirve en última instancia para que el programa servidor y el cliente lean y escriban la información. Esta información será la transmitida por las diferentes capas de red.

1.3.3RPC
El RPC (del inglés Remote Procedure Call, Llamada a Procedimiento Remoto) es un protocolo que permite a un programa de ordenador ejecutar código en otra máquina remota sin tener que preocuparse por las comunicaciones entre ambos. El protocolo es un gran avance sobre los sockets usados hasta el momento. De esta manera el programador no tenía que estar pendiente de las comunicaciones, estando éstas encapsuladas dentro de las RPC.
Las RPC son muy utilizadas dentro del paradigma cliente-servidor. Siendo el cliente el que inicia el proceso solicitando al servidor que ejecute cierto procedimiento o función y enviando éste de vuelta el resultado de dicha operación al cliente.
Hay distintos tipos de RPC, muchos de ellos estandarizados como pueden ser el RPC de Sun denominado ONC RPC (RFC 1057), el RPC de OSF denominado DCE/RPC y el Modelo de Objetos de Componentes Distribuidos de Microsoft DCOM, aunque ninguno de estos es compatible entre sí. La mayoría de ellos utilizan un lenguaje de descripción de interfaz (IDL) que define los métodos exportados por el servidor.

1.3.4CORBA

CORBA fue definido y está controlado por el Object Management Group (OMG) que define las APIs, el protocolo de comunicaciones y los mecanismos necesarios para permitir la interoperabilidad entre diferentes aplicaciones escritas en diferentes lenguajes y ejecutadas en diferentes plataformas, lo que es fundamental en computación distribuida.

En un sentido general, CORBA "envuelve" el código escrito en otro lenguaje, en un paquete que contiene información adicional sobre las capacidades del código que contiene y sobre cómo llamar a sus métodos. Los objetos que resultan, pueden entonces ser invocados desde otro programa (u objeto CORBA) desde la red. En este sentido CORBA se puede considerar como un formato de documentación legible por la máquina, similar a un archivo de cabeceras, pero con más información.

CORBA utiliza un lenguaje de definición de interfaces (IDL) para especificar las interfaces con los servicios que los objetos ofrecerán. CORBA puede especificar a partir de este IDL, la interfaz a un lenguaje determinado, describiendo cómo los tipos de dato CORBA deben ser utilizados en las implementaciones del cliente y del servidor. Implementaciones estándar existen para Ada, C, C++, Smalltalk, Java, Python, Perl y Tcl.

Al compilar una interfaz en IDL se genera código para el cliente y el servidor (el implementador del objeto). El código del cliente sirve para poder realizar las llamadas a métodos remotos. Es el conocido como stub, el cual incluye un proxy (representante) del objeto remoto en el lado del cliente. El código generado para el servidor consiste en unos skeletons (esqueletos) que el desarrollador tiene que rellenar para implementar los métodos del objeto.

CORBA es más que una especificación multiplataforma, también define servicios habitualmente necesarios como seguridad y transacciones. Y así este no es un sistema operativo en si, en realidad es un middleware.





OBJETIVOS:

Profundizar en algunos aspectos de los Sistemas de Gestión de Bases de Datos como optimización de preguntas y control de concurrencia, así como en el diseño físico de bases de datos.
Diseño de Sistemas de Información heterogéneos y distribuidos aplicando los conocimientos adquiridos en todas las asignaturas de la Materia.
Presentar algunas de las tendencias de investigación en bases de datos prestando más atención a aquéllas que parecen tener un mayor impacto en el mercado (para las que existen sistemas comerciales).
Debido al enfoque de la asignatura, se recomienda para alumnos que cursen su último año de carrera, y que hayan cursado previamente la asignatura "Diseño de Bases de Datos Relacionales" e "Ingeníeria del Software II".
PROGRAMA:

PARTE I : ASPECTOS IMPORTANTES EN SGBD Y DISEÑO DE BD.

- Optimización de preguntas.
- Diseño físico.
- Transacciones, recuperación y control de concurrencia.
PARTE II : INTERACCION DE APLICACIONES CON BASES DE DATOS

- Acceso Básico. Casos especiales.
- SQL Embebido
- Uso de un API
Tipos de API´s
ODBC. Drivers.
- WWW
PARTE III : BASES DE DATOS ORIENTADAS A OBJETOS

- Motivación
- Conceptos básicos
- Persistencia : C++ persistente.
- Diseño de bases de datos orientadas a objetos.
- ODE : Un sistema de gestión de bases de datos orientado a objetos.
- Crítica a los SGBDOO
PARTE IV : BASES DE DATOS DISTRIBUIDAS

- Motivación
- Arquitecturas de Sistemas de Bases de Datos Distribuidas
Factores importantes : autonomía, heterogeneidad, distribución y esquema global
Sistemas de Bases de Datos Distribuidas
Sistemas de Bases de Datos Interoperantes
Sistemas de Bases de Datos Federadas
Arquitecturas Cliente/Servidor para SGBD
Filosofía Cliente/Servidor
Sockets
RPC
CORBA
- Diseño de bases de datos distribuidas
Diseño top-down : fragmentación.
Diseño bottom-up : integración de bases de datos.
- Otros aspectos : optimización de preguntas y transacciones.
PARTE V : OTRAS TENDENCIAS

- Bases de Datos Activas.
- Bases de Datos Deductivas.
1.4 Optimización de preguntas y transacciones
xuaxpedia.blogspot.com/.../sgbd-sgbdr-y-arquitectura.html
es.wikipedia.org/wiki/Bases_de_datos_distribuidas
revistas.mes.edu.cu/.../02...Bases_de_Datos_Distribuidas.../file
html.rincondelvago.com/bases-de-datos-distribuidas_1.html