viernes, 2 de diciembre de 2016

Unidad IV. Esquemas de seguridad

4. 1 Seguridad y respaldos Copia de Seguridad o Respaldo

Una "copia de seguridad", "copia de respaldo" o también llamado "backup" (su nombre en inglés) en tecnologías de la información e informática es una copia de los datos originales que se realiza con el fin de disponer de un medio para recuperarlos en caso de su pérdida.

Las copias de seguridad son útiles ante distintos eventos y usos: recuperar los sistemas informáticos y los datos de una catástrofe informática, natural o ataque; restaurar una pequeña cantidad de archivos que pueden haberse eliminado accidentalmente, corrompido, infectado por un virus informático u otras causas; guardar información histórica de forma más económica que los discos duros y además permitiendo el traslado a ubicaciones distintas de la de los datos originales; etc.

El proceso de copia de seguridad se complementa con otro conocido como restauración de los datos (en inglés restore), que es la acción de leer y grabar en la ubicación original u otra alternativa los datos requeridos.

La pérdida de datos es muy común, el 66% de los usuarios de Internet han sufrido una seria pérdida de datos en algún momento.

Ya que los sistemas de respaldo contienen por lo menos una copia de todos los datos que vale la pena salvar, deben de tenerse en cuenta los requerimientos de almacenamiento. La organización del espacio de almacenamiento y la administración del proceso de efectuar la copia de seguridad son tareas complicadas.

Para brindar una estructura de almacenamiento es conveniente utilizar un modelo de almacenaje de datos. Actualmente (noviembre de 2010), existen muchos tipos diferentes de dispositivos para almacenar datos que son útiles para hacer copias de seguridad, cada uno con sus ventajas y desventajas a tener en cuenta para elegirlos, como duplicidad, seguridad en los datos y facilidad de traslado.

Antes de que los datos sean enviados a su lugar de almacenamiento se lo debe seleccionar, extraer y manipular. Se han desarrollado muchas técnicas diferentes para optimizar el procedimiento de efectuar los backups. Estos procedimientos incluyen entre otros optimizaciones para trabajar con archivos abiertos y fuentes de datos en uso y también incluyen procesos de compresión, cifrado, y procesos de duplicación, entendiéndose por esto último a una forma específica de compresión donde los datos superfluos son eliminados.

Muchas organizaciones e individuos tratan de asegurarse que el proceso de backup se efectúe de la manera esperada y trabajan en la evaluación y la validación de las técnicas utilizadas. También es importante reconocer las limitaciones y losfactores humanos que están involucrados en cualquier esquema de backup que se utilice. Las copias de seguridad garantizan dos objetivos: integridad y disponibilidad.

4.1.1 Espejeo

El Mirroring (Base de Datos Espejo) proporciona una solución de alta disponibilidad de bases de datos, aumenta la seguridad y la disponibilidad, mediante la duplicidad de la base de datos.

Esta tecnología está disponible a partir de la versión de SQL Server 2005 (es la evolución del log shipping presente en versiones anteriores).

En el Mirroring tenemos un servidor principal/primario que mantiene la copia activa de la base de datos (bbdd accesible). Otro servidor de espejo que mantiene una copia de la base de datos principal y aplica todas las transacciones enviadas por el Servidor Principal (en el que no se podrá acceder a la bbdd). Y un servidor testigo/arbitro que permite recuperaciones automáticas ante fallos, monitoriza el servidor principal y el de espejo para en caso de caída cambiar los roles (servidor opcional, no es obligatorio).

Existen varios tipos de mirroring:

  • Alta disponibilidad: Garantiza la consistencia transaccional entre el servidor principal y el servidor de espejo y ofrece Automatic Fail over mediante un servidor testigo.
  • Alta Protección: Garantiza la consistencia transaccional entre el servidor principal y el espejo.
  • Alto Rendimiento: Aplica las transacciones en el Servidor Espejo de manera asíncrona ocasionando mejoras significativas en el rendimiento del servidor principal pero no garantiza que dichas transacciones se hallan realizado de manera exitosa en el espejo.

Espejeo de Datos en un DBMS.
Base de Datos Espejo (Database Mirroring).

Donde actúan dos servidores o más para mantener copias de la base de datos y archivo de registro de transacciones.

El servidor primario como el servidor espejo mantienen una copia de la base de datos y el registro de transacciones, mientras que el tercer servidor, llamado el servidor árbitro, es usado cuando es necesario determinar cuál de los otros dos servidores puede tomar la propiedad de la base de datos. El árbitro no mantiene una copia de la base de datos. La configuración de los tres servidores de base de datos (el primario, el espejo y el árbitro) es llamado Sistema Espejo (Mirroring System), y el servidor primario y espejo juntos son llamados Servidores Operacionales (Operational Servers) o Compañeros (Partners).

Beneficios del espejeo de Datos en un DBMS

Esta característica tiene 3 modalidades que son Alto rendimiento, Alta Seguridad, y Alta Disponibilidad, este caso estamos hablando de las 2 primeras, las cuales el levantamiento es manual.
La creación de reflejo de la base de datos es una estrategia sencilla que ofrece las siguientes ventajas:

  • Incrementa la disponibilidad de una base de datos.
  • Si se produce un desastre en el modo de alta seguridad con conmutación automática por error, la conmutación por error pone en línea rápidamente la copia en espera de la base de datos, sin pérdida de datos. En los demás modos operativos, el administrador de bases de datos tiene la alternativa del servicio forzado (con una posible pérdida de datos) para la copia en espera de la base de datos. Para obtener más información, vea Conmutación de roles, más adelante en este tema.
  • Aumenta la protección de los datos.
  • La creación de reflejo de la base de datos proporciona una redundancia completa o casi completa de los datos, en función de si el modo de funcionamiento es el de alta seguridad o el de alto rendimiento. Para obtener más información, vea Modos de funcionamiento, más adelante en este tema.
Un asociado de creación de reflejo de la base de datos que se ejecute en SQL Server 2008 Enterprise o en versiones posteriores intentará resolver automáticamente cierto tipo de errores que impiden la lectura de una página de datos. El socio que no puede leer una página, solicita una copia nueva al otro socio. Si la solicitud se realiza correctamente, la copia sustituirá a la página que no se puede leer, de forma que se resuelve el error en la mayoría de los casos. Para obtener más información, vea Reparación de página automática (grupos de disponibilidad/creación de reflejo de base de datos).

Mejora la disponibilidad de la base de datos de producción durante las actualizaciones.

Para minimizar el tiempo de inactividad para una base de datos reflejada, puede actualizar secuencialmente las instancias de SQL Server que hospedan los asociados de creación de reflejo de la base de datos. Esto incurrirá en el tiempo de inactividad de solo una conmutación por error única. Esta forma de actualización se denomina actualización gradual. Para obtener más información, vea Instalar un Service Pack en un sistema con un tiempo de inactividad mínimo para bases de datos reflejadas.

Métodos de respaldo de un DBMS

Archivo de log

  • Identificador de la transacción
  • Hora de modificación
  • Identificador del registro afectado
  • Tipo de acción
  • Valor anterior del registro
  • Nuevo valor del registro
  • Información adicional

Checkpoint

  • Técnicas basadas en el registro histórico
  • Paginación en la sombra o páginas en espejo
  • Técnica de Recuperación Aries

4.1.2 Réplica

La replicación copia y mantiene los objetos de las bases de datos en las múltiples bases de datos que levantan un sistema distribuido. La replicación puede mejorar el funcionamiento y proteger la disponibilidad de las aplicaciones, porque alternan opciones de acceso de los datos existentes. Por ejemplo, una aplicación puede tener acceso normalmente a una base de datos local, más que a un servidor remoto para reducir al mínimo el tráfico de la red y alcanzar su funcionamiento máximo. Además, la aplicación puede continuar funcionando si el servidor local experimenta una falla, pero otros servidores con datos replicados siguen siendo accesibles.

La replicación se proporciona en los siguientes niveles:

  • Replicación básica: las réplicas de tablas se gestionan para accesos de sólo lectura. Para modificaciones, se deberá acceder a los datos del sitio primario.
  • Replicación avanzada (simétrica): amplían las capacidades básicas de sólo- lectura de la replicación, permitiendo que las aplicaciones hagan actualizaciones a las réplicas de las tablas, a través de un sistema replicado de la base de datos. Con la replicación avanzada, los datos pueden proveer lectura y acceso a actualizaciones a los datos de las tablas.

Modelo de replicación:

El modelo de Replicación que usa SQL es el de “Publicador – Suscriptor”. Este modelo consiste en Publicadores, Suscriptores y Distribuidores; las publicaciones y los artículos, y las suscripciones por tirón o empuje. Además, incorpora agentes de administración como Agente de Instantánea, Agente Lector de Registro, Agente de Distribución, y Agente de Mezcla. Todos los agentes pueden funcionar debajo del agente del servidor del SQL y se pueden administrar completamente por el Administrador del Servidor de SQL.

4.1.3 Métodos de respaldo

En mySQL existen varios métodos para la realización de un backup y esto se debe principalmente a que mySQL guarda las tablas como archivos y al tipo de tablas que se esté manejando (InnoDB, MyISAM, ISAM). Así por ejemplo para la presente práctica se utilizó el tipo de tabla InnoDB y el método de backup utilizado es el que funciona con este tipo de tablas.

InnoDB es una de las tecnologías de almacenamiento que utiliza mySQL, es de código abierto. Entre sus características principales están que soporta transacciones con características ACID (Atomicidad, Consistencia, Aislamiento y Durabilidad), tiene bloque de registros e integridad referencial (cosa que no maneja ISAM, ni myISAM). Esta última es una de sus características más importantes pues una base de datos sin integridad referencial, es nada más un conjunto de datos que no denotan información.

Este tipo de almacenamiento también ofrece una alta fiabilidad y consistencia. El mismo gestiona el control de los datos y no se lo deja al sistema operativo, una de sus desventajas es que no tiene una buena compresión de datos, por lo que ocupa un poco más de espacio que myISAM

Elementos y frecuencia de respaldo

Normalmente cuando uno plantea que va a respaldar los datos de su PC a una persona en una compañía uno tiene que definir muy bien cuál es la información crítica para la empresa, por ejemplo, la música que guarde un empleado en su PC no es crítica para las actividades de la empresa ni lo son las fotos de su última fiesta. En cambio, su correo electrónico, proyectos, informes y papeles administrativos si lo suelen ser y tener un respaldo de estos es clave para el funcionamiento de la empresa en caso de cualquier eventualidad. Normalmente la data o información que es respaldada por las empresas es: 
  • Archivos creados por aplicaciones, como por ejemplo .doc, .odt, .xls, .mdb, pdf, .ppt entre otros.
  • Archivos de correo electrónico
  • Directorios telefónicos y de contactos
  • Favoritos de los navegadores como Firefox e Internet Explorer
  • Base de datos Configuraciones de los equipos
  • Archivos de CAD, PSD, XCF, etc.
  • Imágenes y Fotografías de proyectos
  • Configuraciones de servicios

4.1.4 Métodos de recuperación

Cuando se trata de la recuperación de bases de datos distribuidas hay dos principales preocupaciones que deben de ser abordadas:

Integridad de datos. La base de datos distribuida debe ser restaurada o reparada de tal manera que no exista la corrupción. En términos generales, esto requiere que el proceso de recuperación de la base de datos distribuida sea consciente de las aplicaciones.

El software utilizado por la operación de recuperación tiene que conocer los requisitos específicos de la base de datos que está siendo recuperada. Por ejemplo, la mayoría de las aplicaciones de respaldo de clase empresarial soportan Exchange Server. Este soporte de Exchange Server significa que la aplicación respaldo sabe cómo manejar los puestos de control de la base de datos y los registros de transacciones de procesos como parte del proceso de recuperación.

Recuperación de punto en el tiempo. Por ejemplo, si está recuperando una base de datos de Active Directory en un controlador de dominio, es posible que desee desplegar el Active Directory de vueltaa un punto específico en el tiempo.

El problema es que Active Directory utiliza una base de datos distribuida y otros controladores de dominio están en línea. Cuando el proceso de recuperación de la base de datos distribuida se completa, el controlador de dominio recién restaurado alcanzará a otros controladores de dominio e iniciará un proceso de sincronización.

Esto trae al controlador de dominio recién restaurado a un estado actual que es consistente con los otros controladores de dominio. Si su objetivo era desplegar Active Directory de vuelta a un punto anterior en el tiempo, el proceso de sincronización deshará sus esfuerzos de recuperación. La solución para las bases de datos distribuidas es llevar a cabo una recuperación autoritaria, lo que esencialmente causa que el controlador de dominio recién restaurado sea tratado como la copia correcta de la base de datos de Active Directory.

En los entornos distribuidos de datos podemos encontrar lo siguientes:

Fallo de los nodos. Cuando un nodo falla, el sistema deberá continuar trabajando con los nodos que aún funcionan. Si el nodo a recuperar es una base de datos local, se deberán separar los datos entre los nodos restantes antes de volver a unir de nuevo el sistema.

Copias múltiples de fragmentos de datos. El subsistema encargado del control de concurrencia es el responsable de mantener la consistencia en todas las copias que se realicen y el subsistema que realiza la recuperación es el responsable de hacer copias consistentes de los datos de los nodos que han fallado y que después se recuperarán.

Transacción distribuida correcta. Se pueden producir fallos durante la ejecución de una transacción correcta si se plantea el caso de que al acceder a alguno de los nodos que intervienen en la transacción, dicho nodo falla.

Fallo de las conexiones de comunicaciones. El sistema debe ser capaz de tratar los posibles fallos que se produzcan en las comunicaciones entre nodos. El caso mas extremo es el que se produce cuando se divide la red. Esto puede producir la separación de dos o más particiones donde las particiones de cada nodo pueden comunicarse entre si pero no con particiones de otros nodos.

Para implementar las soluciones a estos problemas, supondremos que los datos se encuentran almacenados en un único nodo sin repetición. De ésta manera sólo existirá un único catálogo y un único DM (Data Manager) encargados del control y acceso a las distintas partes de los datos.

Para mantener la consistencia de los datos en el entorno distribuido contaremos con los siguientes elementos:

  • Catálogo: Programa o conjunto de programas encargados de controlar la ejecución concurrente de las transacciones.
  • CM (Cache Manager). Subsistema que se encarga de mover los datos entre las memorias volátiles y no volátiles, en respuesta a las peticiones de los niveles más altos del sistema de bases de datos. Sus operaciones son Fetch(x) y Flush(x).
  • RM (Recovery Manager). Subsistema que asegura que la base de datos contenga los efectos de la ejecución de transacciones correctas y ninguno de incorrectas. Sus operaciones son Start, Commit, Abort, Read, Write, que utilizan a su vez los servicios del CM.
  • DM (Data Manager). Unifica las llamadas a los servicios del CM y el RM.
  • TM (Transaction Manager). Subsistema encargado de determinar que nodo deberá realizar cada operación a lo largo de una transacción.
Las operaciones de transacción que soporta una base de datos son: Start, Commit y Abort. Para comenzar una nueva transacción se utiliza la operación Start. Si aparece una operación commit, el sistema de gestión da por terminada la transacción con normalidad y sus efectos permanecen en la base de datos. Si, por el contrario, aparece una operación abort, el sistema de gestión asume que la transacción no termina de forma normal y todas las modificaciones realizadas en la base de datos por la transacción deben de ser deshechas.

4.2 Migración

La migración de bases de datos es generalmente una tarea compleja que no sólo supone transferir datos entre tipos de almacenaje y formatos de un servidor de base de datos a otro; sino que también supone reescribir sentencias SQL o incluso procedimientos (SPL) de lógica de negocio.

En comparación con los esquemas estándares de migración a mano, ofrecemos una potente gama de herramientas desarrolladas de probada eficacia en complejos módulos de bases de datos relacionales. Estas herramientas y nuestros especialistas pueden asegurar que las transiciones de las bases de datos se realicen perfectamente, independientemente de la naturaleza del sistema.

Desde la experiencia, estamos familiarizados con la complejidad, el coste que supone una larga migración de bases de datos y los problemas que aparecen durante el proceso cuando se emplean métodos inapropiados; ya que siempre comprobamos con los clientes potenciales que el uso de nuestras herramientas y métodos pueda ofrecer una ventaja significativa.

HERRAMIENTAS DE MIGRACIÓN

En comparación con la consultoría estándar de migraciones, la cual puede ofrecer poco más que soporte a la base de datos, nosotros tenemos gran experiencia en escribir grandes aplicaciones para empresas en sintaxis de la base de datos nativa y cross. Además, enseñamos a los equipos de las empresas una metodología y les proporcionamos una potente gama de herramientas para reducir costes y optimizar el proceso de migración.

4.3 Monitoreo

El término Monitoreo es un término no incluido en el diccionario de la Real Academia Española (RAE). Su origen se encuentra en monitor, que es un aparato que toma imágenes de instalaciones filmadoras o sensores y que permite visualizar algo en una pantalla. El monitor, por lo tanto, ayuda a controlar o supervisar una situación.

Esto nos permite inferir que monitoreo es la acción y efecto de monitorear, el verbo que se utiliza para nombrar a la supervisión o el control a través de un monitor. Por extensión, el monitoreo es cualquier acción de este tipo, más allá de la utilización de un monitor.

Monitoreo general de un DBMS


DAP— un término que Gartner desarrolló para remplazar el anterior concepto de DAM —se refiere a las suites de herramientas que se utilizan para apoyar la identificación y reportar comportamiento inapropiado, ilegal o de otra forma indeseable en las RDBMSs, con mínimo impacto en las operaciones y la productividad del usuario.

Estas suites han evolucionado de herramientas DAM — que ofrecían análisis de la actividad del usuario en las RDBMSs y alrededor de ellas— para abarcar un conjunto más integral de capacidades, que incluyen:

  • Descubrimiento y clasificación.
  • Gestión de vulnerabilidades.
  • Análisis al nivel de aplicación.
  • Prevención de intrusión.
  • Soporte de seguridad de datos no estructurados.
  • Integración de gestión de identidad y acceso.
  • Soporte de gestión de riesgos.

Monitoreo general de un DBMS

La elección de un buen manejador de base de datos es de vital importancia ya que puede llegar a ser una inversión tanto en hardware como en software muy cuantioso, pero no solo eso, además va a determinar el centro de información de la empresa.

Los sistemas orientados a los datos se caracterizan porque los datos no son de una aplicación sino de una Organización entera que los va a utilizar; se integran las aplicaciones, se diferencian las estructuras lógicas y físicas. El concepto de relación cobra importancia. Originalmente las aplicaciones cubrían necesidades muy específicas de procesamiento, se centraban en una tarea específica.

Monitoreo de espacio en disco

Uno de los principales indicadores que se tiene que tomar en cuenta como DBA es el espacio disponible en disco. No es problema cuando se tiene un server o 2 para monitorear, sin embargo, cuando hay una cantidad considerable automatizar un proceso que lo haga es lo mejor. Dentro de SQL Server (7,2000,2005) hay un procedimiento no documentado que nos puede ayudar a cumplir este cometido.

El procedimiento es XP_FIXEDDRIVES, no lleva parámetros ni nada y nos regresan todos los discos a los que tiene acceso SQL Server y su espacio disponible en Megabytes. Si esta en clúster mostrara todos los discos, aunque los discos no estén en el mismo grupo que la instancia, lo que puede llegar a confundir.

Dejo a consideración de cada quien como utilizarlo, ya sea mandando un mail con el resultado u opciones más complejas como el revisar un porcentaje y en base a eso tomar una acción.

Monitoreo de logs

Las revisiones deben realizarse sobre el archivo de alerta de ORACLE (alert.log) y sobre los archivos de rastreo de procesos de background y de usuarios para identificar errores que se presenten a nivel de base de datos o de sistema operativo.

Los archivos de alerta útiles para el diagnóstico de información que contiene ORACLE y que se utilizan para la detección de errores en la base de datos son:

Archivo de Logs de alerta (alert.log)

El Alert Log registra errores en forma cronológica, provenientes de la operación diaria de la Base de Datos. La ubicación actual del archivo es la ubicación por defecto establecida por ORACLE y se verifica mediante el parámetro BACKGROUND_DUMP_DEST del archivo init.ora:

BACKGROUND_DUMP_DEST = E:\U01\ORACLE\UCBL\ADMIN\bdump

La revisión de este archivo en forma periódica permite detectar errores internos (ORA-600) y errores de corrupción de bloques (ORA-1578). Adicionalmente, permite monitorear las operaciones de la base de datos (CREATE DATABASE, STARTUP, SHITDOWN, ARCHIVE LOG y RECOVER) y ver los parámetros que no se muestran por defecto en la inicialización. Fuente: http://proyecto359.webnode.mx/unidad5/

4.4 Auditoría

Auditoria: Es el proceso que permite medir, asegurar, demostrar, monitorear y registrar los accesos a la información almacenada en las bases de datos incluyendo la capacidad de determinar:
  • Quién accede a los datos 
  • Cuándo se accedió a los datos
  • Desde qué tipo de dispositivo/aplicación
  • Desde que ubicación en la Red
  • Cuál fue la sentencia SQL ejecutada
  • Cuál fue el efecto del acceso a la base de datos

objetivo de: 


  • Mitigar los riesgos asociados con el manejo inadecuado de los datos. 
  • Apoyar el cumplimiento regulatorio.
  • Satisfacer los requerimientos de los auditores.
  • Evitar acciones criminales.
  • Evitar multas por incumplimiento.


Unidad III. Sistemas de Multibase de Datos.

3.1. Características y clasificación.

Un sistema multibase de datos (SMulBD) soporta operaciones en múltiples sistemas de base de datos componentes (SBDC). Cada SBDC es manejado por un sistema manejador de base de datos (SMBD). Un SBDC en un SMulBD puede ser centralizado o distribuido y puede residir en la misma computadora o en múltiples computadoras conectadas por un subsistema de comunicación. Un SMulBD es llamado homogéneo si todos los SMBD componentes son iguales; si son diferentes entonces es llamado un SMulBD heterogéneo.

Sheth y Larson [1990] proponen la taxonomía mostrada en la siguiente figura para comparar las arquitecturas de diversos esfuerzos de investigación y desarrollo. Esta taxonomía se enfoca en la dimensión de autonomía.
Clasificación de los Sistemas Multibase de Datos

Un SMulBD puede ser clasificado en dos tipos basados en la autonomía de la SBDCs: sistemas de base de datos no-federada y sistemas de base de datos federada.

  1. Sistema de Base de Datos No-Federada: Un sistema de base de datos no federado es una integración de SMBDs componentes que no son autónomos. Esto significa que los SBDCs al participar en una federación pierden su autonomía y cualquier operación debe hacerse sobre la base de datos global. Un sistema de este tipo no distingue entre usuarios locales y usuarios no-locales. Un tipo particular de sistema de base de datos no-federado en el cual todas las bases están completamente integradas para proveer un esquema global simple puede ser llamado SMulBD unificado. Esto lógicamente parece a los usuarios como un sistema de base de datos distribuida.
  2. Sistema de Base de Datos Federada: Un sistema de base de datos federada (SBDF) consiste de SBDCs que son autónomos, participan en una federación para permitir compartición parcial y controlada de sus datos. El concepto de autonomía implica que los SBDCs tienen control sobre los datos que ellos manejan. Ellos cooperan para permitir diversos grados de integración. No hay control centralizado en una arquitectura federada debido a que los SBDCs (y sus administradores de base de datos) controlan el accesos a sus datos. Para permitir la compartición controlada de datos mientras preserva la autonomía de los SBDCs y continuar con la ejecución de aplicaciones existentes, un SBDF soporta dos tipos de operaciones: local y global (federación). Esta división de operaciones globales y locales es una característica esencial de un SBDF. Las operaciones globales involucran acceso a los datos usando un sistema manejador de base de datos federado y puede involucrar manejar datos por múltiples SBDCs. Los SBDCs deben dar permisos de accesar los datos que ellos manejan. Las operaciones locales son sometidas aun SBDC directamente. En la mayoría de los ambientes los SBDF también serán heterogéneos, es decir, consistirán de SBDCs heterogéneos.

3.2. Arquitectura de un sistema de multibase de datos.

Un esquema global en los SBDFs fuertemente acoplados es el resultado de la integración de los esquemas de exportación de las bases de datos componentes. Un lenguaje de consulta global es utilizado por los usuarios del sistema de base de datos federada para especificar consultas contra el esquema global.

Para procesar una consulta global, la consulta primero es analizada y después descompuesta en unidades de consulta las cuales son representadas en la forma de un grafo de unidades de consulta. El Generador del Plan de Ejecución construye subconsultas a partir del grafo de unidades de consulta y estima su costo de ejecución. El plan de consulta con el costo estimado mínimo será enviado al despachador el cual será el encargado de coordinar la ejecución de las consultas. Por último, los resultados de las consultas son combinados para construir los resultados de la consulta global.
Arquitectura de un sistema de multibase de datos Federada

Arquitectura de un Sistema de Base de Datos Federada

Sheth y Larson [1990] proponen una arquitectura de 5 niveles de esquemas para un SBDF: esquema local, esquema componente, esquema de exportación, esquema federado y esquema externo:

  • Esquema Local. Un esquema local es el esquema conceptual del SBDC.
  • Esquema Componente. Un esquema componente es derivado de trasladar el esquema local en un modelo de datos llamado canónico o modelo de datos común.
  • Esquema de Exportación. Un esquema de exportación representa un subconjunto de un esquema componente que está disponible para el SBDF.
  • Esquema Federado. Un esquema federado es una integración de múltiples esquemas de exportación. Este esquema también incluye la información de la distribución de datos que es generada cuando se integran los esquemas de exportación.
  • Esquema Externo. Un esquema externo define un esquema para un usuario y/o aplicación. Este esquema puede ser usado para especificar un subconjunto de la información en el esquema federado.

Arquitectura de un SBDF con 5 niveles de esquemas [ Sheth y Larson 1990]

Un SBDF puede ser categorizado como débilmente acoplado o fuertemente acoplado basado en la idea de quien maneja la federación y como los componentes son integrados.

Sistemas de Base de Datos Federada Débilmente Acoplados

Un SBDF es débilmente acoplado si la responsabilidad de crear y mantener la federación recae en el usuario y no hay control por parte del sistema federado y sus administradores. Litwin et al. [1990] se refiere a este mismo concepto como multibases de datos o bases de datos interoperables. Asumen que los usuarios necesitan accesar múltiples datos sin el beneficio de un esquema global y que el componente esencial de un sistema de este tipo es el lenguaje usado para manejar las bases de datos participantes. Otro requerimiento importante es que el usuario debe ser capaz de formular manipulaciones multibase de datos no procedurales en la ausencia de un esquema global. El usuario es responsable de comprender la semántica de los objetos en los esquemas de exportación y resolver la heterogeneidad de los SMBDs y de la semántica.

El lenguaje multibase de datos debe permitir a los usuarios definir y manipular una colección de bases de datos autónomas en una forma no procedural. Tal lenguaje necesita características que no son parte de lenguajes de bases de datos, esto debido a que los SMBDs clásicos fueron desarrollados para una sola base de datos. En Litwin y Abdellalit [1987] se describen las características de MDSL un lenguaje de manipulación multibase de datos.

Sistemas de Base de Datos Federada Fuertemente Acoplados

Una Federación es fuertemente acoplada si su administrador (es) tiene la responsabilidad de crear y mantener la federación y el control de acceso a los SBDCs. Una federación está compuesta por una integración selectiva y controlada de sus componentes. La actividad de desarrollar un SBDF fuertemente acoplado consiste en la creación de un esquema federado sobre el cual las operaciones (consultas y/o actualizaciones) son ejecutadas.

Un SBDF fuertemente acoplado puede tener uno o más esquemas federados. Un SBDF fuertemente acoplado se dice que tiene una federación sencilla si permite la creación y manejo de solamente un esquema federado. Tener un esquema federado sencillo ayuda a mantener la uniformidad en la interpretación semántica de los datos integrados. Un SBDF fuertemente acoplado se dice que tiene una federación múltiple si permite la creación y manejo de múltiples federaciones. Las restricciones involucradas en múltiples SBDCs, sin embargo, puede ser difícil de imponer.

Un SBDF fuertemente acoplado provee localización, duplicación y transparencia de distribución. Esto es llevado a cabo al desarrollar un esquema federado que integra múltiples esquemas de exportación. Las transparencias son manejadas por los mapeos entre el esquema federado y los esquemas de exportación, y un usuario de la federación puede hacer consultas a través de un lenguaje de consultas clásico contra el esquema federado con la ilusión de que se está accesando un solo sistema [Sheth y Larson 1990].

Debido a que un esquema federado es creado al integrar todos los esquemas de exportación y porque este esquema federado soporta los requerimientos de datos de todos los usuarios, este puede llegar a ser demasiado grande y por tanto difícil de crear y mantener.

3.3. Procesamiento de operaciones de actualización.

Todas las operaciones financieras relativas a la gestión de un pedido se almacenan temporalmente en un fichero de pagos hasta que se lleva a cabo su procesamiento. Es en este momento cuandolos datos se actualizan en los campos correspondientes de los ficheros del sistema y todas las transacciones realizadas pasan al fichero histórico de pagos. Asimismo, al procesar las operaciones toda la información relativa a ellas debe imprimirse necesariamente.

El procesamiento de las operaciones (que se realizará de forma centralizada en los Servicios Centrales), tiene una importancia, pues, fundamental para la correcta gestión de las adquisiciones, por lo que hemos decidido dedicarle un apartado independiente.

3.4. Procesamiento de consultas.

El proceso de consultas en bases de datos relacionales deja al programador de aplicaciones en un escenario distinto al anterior; la razón es el empleo de lenguajes de especificación: “si se utiliza un lenguaje de especificación el programador no tiene que diseñar ni generar un método para ejecutar la especificación o consulta requerida”, es decir el programador es introducido en un escenario “no procedural”, “no está obligado a crear métodos ni procedimientos para obtener los datos, sólo a especificar los datos que requiere”. Ejemplo: si en un programa de aplicación se inserta una instrucción SQL del tipo:

SELECT NoMatricula, Nombre, Asignatura, Nota FROM notas WHERE curso= “3º”

Lo único que está aportando el programador es la especificación de los datos requeridos (¿qué datos requiere?), pero a diferencia de la obtención de datos en un ambiente de archivos convencionales no especifica el algoritmo o método de obtención (¿cómo o por qué camino obtenerlos?).

3.5 Aplicaciones multibase de datos

Las BDs Heterogéneas o Multibase de Datos son aquellas donde Sitios diferentes utilizan diferentes DBMS’s, siendo cada uno esencialmente autónomo.

Es posible que algunos sitios no sean conscientes de la existencia de los demás y quizás proporcionen facilidades limitadas para la cooperación en el procesamiento de transacciones en las bases de datos distribuidas heterogéneas puede que los diferentes sitios utilicen esquemas y software de gestión de sistemas de bases de datos diferentes. Puede que algunos sitios no tengan información de la existencia delresto y que sólo proporcionen facilidades limitadas para la cooperación en el procesamiento de las transacciones.

La heterogeneidad se debe a que los datos de cada BD son de diferentes tipos o formatos. El enfoque heterogéneo es más complejo que el enfoque homogéneo. Hoy en día existe la tendencia a crear software que permita.

Tener acceso a diversas bases de datos autónomas preexistentes almacenadas en SGBD heterogéneos.

La Heterogeneidad de las BDs es inevitable cuando diferentes tipos de BD coexisten en una organización que trata de compartir datos entre éstas BDD heterogéneamente: El tratamiento de la información ubicada en bases de datos distribuidas heterogéneas exige una capa de software adicional por encima de los sistemas de bases de datos ya existentes.

Esta capa de software se denomina sistema de bases de datos múltiples. Puede que los sistemas locales de bases de datos empleen modelos lógicos y lenguajes de definición y de tratamiento de datos diferentes, y que difieran en sus mecanismos de control de concurrencia y de administración de las transacciones.

jueves, 1 de diciembre de 2016

Unidad II. Sistemas de bases de datos orientadas a objetos

2.1. El modelo de datos orientado a objetos.

Desde la aparición de la programación orientada a objetos (POO u OOP) se empezó a pensar en bases de datos adaptadas a estos lenguajes.

La programación orientada a objetos permite cohesionar datos y procedimientos, haciendo que se diseñen estructuras que poseen datos y procedimientos; haciendo que se diseñen estructuras que poseen datos (atributos) en las que se definen los procedimientos (operaciones) que pueden realizar con los datos. En las bases orientadas a objetos se utiliza esta misma idea.

A través de este concepto se intenta que estas bases de datos consigan arreglar las limitaciones de las relacionales. Por ejemplo, el problema de la herencia (el hecho de que no se puedan realizar relaciones de herencia entre las tablas), tipos definidos por el usuario, disparadores (triggers) almacenables en la base de datos, soporte multimedia...

Se supone que son las bases de datos de tercera generación (la primera fue las bases de datos en red y la segunda las relacionales), lo que significa que el futuro parece estar a favor de estas bases de datos. Pero siguen sin reemplazar a las relacionales, aunque son el tipo de base de datos que más está creciendo en los últimos años.

Su modelo conceptual se suele diseñar en UML y el lógico actualmente en ODMG (Object Data Management Group), grupo de administración de objetos de datos, organismo que intenta crear estándares para este modelo.

2.1.1. Características de los SGBDOO.


  1. Debe soportar objetos complejos. Debe ser posible construir objetos complejos aplicando constructores a objetos básicos.
  2. Identidad del objeto. Todos los objetos deben tener un identificador, el cual es independiente de los valores de sus atributos.
  3. Encapsulamiento. Los programadores solo tienen acceso a la interfaz de los métodos, y los datos e implementación de estos métodos están en los objetos.
  4. Tipos o clases. El esquema de una base orientada a objetos contiene un conjunto de clases o tipos.
  5. Tipos o clases deben ser capaces de heredar de sus súper-tipos o superclases los atributos y los métodos.
  6. La sobrecarga debe ser soportada, los métodos deben poder aplicarse a diferentes tipos
  7. El DML debe ser completo. El DML en los sistemas gestores de bases de datos orientados a objetos debe ser un lenguaje de programación de propósito genera
  8. El conjunto de tipos de datos debe ser extensible. No habrá distinción entre los tipos definidos por el usuario y los tipos definidos por el sistema,
  9. Persistencia de datos. Los datos deben mantenerse después de que la aplicación que los creó haya finalizado, el usuario no tiene que hacer copia explícitamente.
  10. El SGBD debe ser capaz de manejar bases de datos grandes.
  11. El SGDB debe soportar la concurrencia. Debe disponer del mecanismo para el control de la concurrencia.
  12. Recuperaci¢n. El sistema gestor debe de proveer mecanismos de recuperación de la información en caso de fallo de sistema.
  13. El SGDB debe proveer de manera fácil de hacer consultas.

2.1.2. Tipos de SGBDOO.

Las Bases de datos orientados a objetos se propusieron con la idea de satisfacer las necesidades de las aplicaciones más complejas. El enfoque orientado a objetos ofrece la flexibilidad para cumplir con algunos de estos requerimientos sin estar limitado por los tipos de datos y los lenguajes de consulta disponibles en los sistemas de bases de datos tradicionales.

Como cualquier Bases de Datos programables, una Base de Datos Orientada a Objetos (BDOO) proporciona un ambiente para el desarrollo de aplicaciones y un depósito persistente listo para su explotación.

Una BDOO almacena y manipula información que puede ser digitalizada (presentada) como objetos, además proporciona un acceso ágil y permite una gran capacidad de manipulación.

Los principales conceptos que se utilizan en las Bases de Datos Orientada a Objetos (BDOO) son las siguientes:

1. Identidad de objetos.
2. Constructores de tipos.
3. Encapsulamiento.
4. Compatibilidad con los lenguajes de programación.
5. Jerarquías de tipos y herencia.
6. Manejo de objetos complejos.
7. Polimorfismo y sobrecarga de operadores.
8. Creación de versiones.

BDOO

Está diseñada para simplificar la POO almacena objetos directamente en la base de datos empleando las mismas estructuras que leguajes de programación.

SGBOO

Es un sistema de objetos y un sistema de base de datos que almacena objetos permitiendo la concurrencia y recuperación. Pueden tratar directamente con los objetos sin hacer la traducción a tablas registros, para los programadores de aplicación (general o específica) los objetos se conservan en su forma y tamaño pueden compartirse con múltiples usuarios.

Niveles de abstracción

1. Interno. - Como se van a guardar los objetos (disco duro).
2. Conceptual. - Como guardar la estructura.
3. Externo. - Lo que vamos a mostrar al usuario (interfaz).

Consideraremos el problema de almacenar un coche en el garaje en un sistema de objetos, el coche es un objeto, el garaje es un objeto y hay una operación simple que es almacena el coche en el garaje. En el sistema relacional todos los datos se traducen en tablas, entonces el coche debe de ser desarmado, las llantas se colocan en un lugar, los birlos en otro lugar, por la mañana antes de salir hay que componer el coche antes de conducir.

Aplicaciones de la BDOO

1. Diseño asistido por computadora CAD.
2. Fabricación asistida por computadora CAM.
3. Ingeniería de software asistido por computadora CASE.
4. Sistemas de gestión de red.
5. Sistemas de información de oficina y sistemas multimedia OIS.
6. Sistema autoedición digital.
7. Sistemas de información geográfica GIS.
8. Sistemas Web interactivos dinámicos.

2.1.3. Productos.

El número de productos para utilizar XML con Bases de Datos está creciendo a una gran velocidad. Nuevos productos entran al mercado de forma constante. Aquí se realiza una clasificación de estos productos, mencionando cuales son las características genéricas de los mismos, que funcionalidades brindan y se analizan algunos de estos productos existentes en el mercado.

Antes de continuar, hay que realizar la aclaración de que los documentos XML pertenecen a dos categorías: "basados en datos" y "basados en documentos". Los documentos XML "basados en datos" son en los que XML es usado como un transporte de datos. Estos son por ejemplo órdenes de compra, registros de pacientes y datos científicos. Los "basados en documentos" son en los que XML es usado para representar documentos, como un manual de usuario, páginas estáticas, folletos de marketing. Este último tipo de documento se caracteriza por su estructura irregular.

Para grabar y recuperar datos en un documento "basados en datos", se necesitará una Base de datos, como puede ser una Base de Datos relacional o una orientada a objetos.

Para grabar y recuperar datos en un documento "basados en documentos", se necesita una Base de Datos de XML o un Sistema de Administración de Contenidos. Ambos están diseñados para almacenar fragmentos del contenido, como procedimientos, capítulos, y glosarios, y pueden incluir metadatos, como nombre del autor, fecha de revisión, etc. Un Sistema de Administración de Contenidos generalmente tiene funcionalidades adicionales, como editores, controladores de versiones, etc. [Bourret R., XML].

En años recientes, han aparecido muchos prototipos experimentales y sistemas de bases de datos comerciales orientados a objetos. Entre los primeros se encuentran los sistemas:

Prototipos Experimentales

  • ORION, OpenOODB, IRIS, ODE y el proyecto ENCORE/ObServer.

Y entre los sistemas disponibles en el mercado están:
Sistemas de Bases de Datos Comerciales Orientados a Objetos

  • GEMSTONE/OPAL de ServicLogic,
  • ONTOS de Ontologic,
  • Objectivity de Objectivity Inc.,
  • Versant de Versant Technologies,
  • ObjecStore de Object Design y
  • O2 de O2 Technology.
Esta es solo una lista parcial de los prototipos experimentales y de los sistemas de bases de datos comerciales orientados a objetos. Desafortunadamente, es aún demasiado pronto para saber cuáles sistemas se instalarán como líderes en este campo.

2.2. El estándar ODMG.

Este Modelo estándar ODMG, especifica los elementos que se definirán, y en qué manera se hará, para la consecución de persistencia en las Bases de datos orientadas a objetos que soporten el estándar. Consta de un lenguaje de definición de objetos, ODL, que especifica los elementos de este modelo. Un grupo de representantes de la industria de las bases de datos formaron el ODMG (Object Database Management Group) con el propósito de definir estándares para los SGBD orientados a objetos. Este grupo propuso un modelo estándar para la semántica de los objetos de una base de datos. Su última versión, ODMG 3.0, apareció en enero de 2000.

El estándar ODMG es un producto de consorcio internacional OMG, el cual principalmente proporciona técnicas orientadas a objetos para la ingeniería de software. Sus estándares pueden ser aceptados por empresas certificadas como ISO. El estándar OSMG es el modelo para la semántica de los objetos de una base de datos. Permite portar tanto los diseños como las implementaciones en diversos sistemas compatibles.

ODMG está compuesto por:

Modelo de Objeto
El modelo de objetos ODMG permite que tanto los diseños, como las implementaciones, sean portables entre los sistemas que lo soportan. Dispone de las siguientes primitivas de modelado:
Los componentes básicos de una base de datos orientada a objetos son los objetos y los literales. Un objeto es una instancia autocontenida de una entidad de interés del mundo real. Los objetos tienen algún tipo de identificador único. Un literal es un valor específico, como “Amparo” o 36. Los literales no tienen identificadores. Un literal no tiene que ser necesariamente un solo valor, puede ser una estructura o un conjunto de valores relacionados que se guardan bajo un solo nombre. Los objetos y los literales se categorizan en tipos. Cada tipo tiene un dominio específico compartido por todos los objetos y literales de ese tipo. Los tipos también pueden tener comportamientos. Cuando un tipo tiene comportamientos, todos los objetos de ese tipo comparten los mismos comportamientos. En el sentido práctico, un tipo puede ser una clase de la que se crea un objeto, una interface o un tipo de datos para un literal (por ejemplo, integer). Un objeto se puede pensar como una instancia de un tipo. Lo que un objeto sabe hacer son sus operaciones. Cada operación puede requerir datos de entrada (parámetros de entrada) y puede devolver algún valor de un tipo conocido. Los objetos tienen propiedades, que incluyen sus atributos y las relaciones que tienen con otros objetos. El estado actual de un objeto viene dado por los valores actuales de sus propiedades. Una base de datos es un conjunto de objetos almacenados que se gestionan de modo que puedan ser accedidos por múltiples usuarios y aplicaciones. La definición de una base de datos está contenida en un esquema que se ha creado mediante el lenguaje de definición de objetos ODL (Object Definition Language) que es el lenguaje de manejo de datos que se ha definido como parte del estándar propuesto para las bases de datos orientadas a objetos.

Lenguaje de definición de objeto ODL

ODL es un lenguaje de especificación para definir tipos de objetos para sistemas compatibles con ODMG. ODL es el equivalente del DDL (lenguaje de definición de datos) de los SGBD tradicionales. Define los atributos y las relaciones entre tipos, y especifica la signatura de las operaciones. La sintaxis de ODL extiende el lenguaje de definición de interfaces (IDL)de la arquitectura CORBA (Common Object Request Broker Architecture).

Lenguaje de Consulta de objetos OQL

OQL es un lenguaje declarativo del tipo de SQL que permite realizar consultas de modo eficiente sobre bases de datos orientadas a objetos, incluyendo primitivas de alto nivel para conjuntos de objetos y estructuras. Está basado en SQL-92, proporcionando un súperconjunto de la sintaxis de la sentencia SELECT.OQL no posee primitivas para modificar el estado de los objetos ya que las modificaciones se pueden realizar mediante los métodos que ́éstos poseen. La sintaxis básica de OQL es una estructura SELECT...FROM...WHERE..., como en SQL.

2.3. Identidad y estructura de objetos

Identidad
La identidad es la propiedad que permite diferenciar a un objeto y distinguirse de otros. Generalmente esta propiedad es tal, que da nombre al objeto. Tomemos por ejemplo el "verde" como un objeto concreto de una clase color; la propiedad que da identidad única a este objeto es precisamente su "color" verde. Tanto es así que para nosotros no tiene sentido usar otro nombre para el objeto que no sea el valor de la propiedad que lo identifica.

En programación la identidad de los objetos sirve para comparar si dos objetos son iguales o no. No es raro encontrar que en muchos lenguajes de programación la identidad de un objeto esté determinada por la dirección de memoria de la computadora en la que se encuentra el objeto, pero este comportamiento puede ser variado redefiniendo la identidad del objeto a otra propiedad.

Estructura
Es la disposición, distribución y orden de las partes del cuerpo de una cosa determinada inanimada, que puede ser perceptible por algún sentido, y se puede accionar sobre ella.

Desglosando la definición, es de considerar que objeto es una cosa, que puede ser material real (materia con una forma definida, que se puede percibir con algún sentido (vista, tacto, etc.), ejemplo una mesa, o una manzana), o abstracta (por ejemplo una idea, o un proyecto que todavía no se concreta o se hace real), y que esa cosa u objeto, está conformado por partes (aún lo más pequeño, como el átomo, se forma por un conjunto de elementos), y las mismas están dispuestas, ordenadas, o acomodadas de tal forma que conforman un cuerpo, ya sea que forme parte de la naturaleza, o haya sido creado por el ser humano (en este caso entonces es una obra de ingenio).
Fuente: http://acrediteme.blogspot.mx/2013/12/unidad-2-sistemas-de-base-de-datos.html

2.4. Encapsulamiento, herencia y polimorfismo en BDOO.

Encapsulamiento
El encapsulamiento se centra en la implementación que da lugar al comportamiento observable de un objeto. El encapsulamiento se consigue a menudo mediante la ocultación de información, es decir, se basa en ocultar todos los secretos de un objeto que no contribuyen a sus características esenciales.

El encapsulamiento proporciona, por tanto, barreras explícitas entre abstracciones diferentes. Existen dos visiones diferentes del encapsulamiento [ATK89], la primera y original que es la del lenguaje de programación; y la segunda que es la adaptación de esa visión para la base de datos.
Desde el punto de vista de las bases de datos, esto se traduce en el hecho de que un objeto abarca operaciones y datos, pero con una diferencia. En las bases de datos no está claro si la parte estructural es parte de la interfaz (depende del sistema), mientras que en los lenguajes de programación la estructura de datos es claramente parte de la implementación y no de la interfaz. Como se puede observar, el encapsulamiento proporciona una forma lógica de independencia de los datos, ya que se puede cambiar la implementación de un tipo sin cambiar ninguno de los programas que usan ese tipo.

Herencia

Las clases o tipos heredan de sus ancestros.

Ventajas de la herencia
  • Ayuda al modelado porque proporciona una descripción concisa y precisa del mundo.
  • Ayuda a compartir especificaciones e implementaciones en las aplicaciones.
  • Tipos de herencia a destacar en los sistemas de gestión de bases de datos
  • Herencia de sustitución: en cualquier lugar donde podamos tener un objeto de tipo podemos sustituirlo por un objeto de tipo t si t hereda de t’.
  • Herencia de restricción: es un subcaso de la herencia de inclusión. Un tipo t es un subtipo de si está formado por todos los objetos de t que satisfacen una restricción dada.
  • Herencia d especialización: un tipo t es un subtipo de t’, si los objetos de tipo t son objetos de tipo t’ que contienen información más específica.

Polimorfismo

Existen casos en los que se desea tener el mismo nombre para diferentes operaciones. Supongamos la operación dibuja que toma un objeto como entrada y lo dibuja en pantalla. Dependiendo del tipo de objeto (cuadrado, estrella, flecha, …) debemos emplear diferentes mecanismos de visualización. Es decir, necesitamos visualizar un conjunto cuyos miembros no se conocen en tiempo de compilación.

En una aplicación que emplee el sistema convencional, habrá tantas operaciones como figuras a representar: dibuja cuadrado, dibuja estrella, dibuja flecha etc. En un sistema orientado a objetos se definirá la operación en una clase más general.

Para proporcionar esta nueva funcionalidad, el sistema no puede asociar los nombres de las operaciones con los métodos correspondientes en tiempo de compilación; se hará en tiempo de ejecución. Esto es lo que se conoce como ligadura tardía y dificulta o imposibilita el chequeo de tipo.

Una base de datos orientada a objetos es una base de datos que incorpora todos los conceptos importantes del paradigma de objetos:

Encapsulación – Propiedad que permite ocultar la información al resto de los objetos, impidiendo así accesos incorrectos o conflictos.
Herencia – Propiedad a través de la cual los objetos heredan comportamiento dentro de una jerarquía de clases.
Polimorfismo – Propiedad de una operación mediante la cual puede ser aplicada a distintos tipos de objetos.

En bases de datos orientadas a objetos, los usuarios pueden definir operaciones sobre los datos como parte de la definición de la base de datos. Una operación (llamada función) se especifica en dos partes. La interfaz (o signatura) de una operación incluye el nombre de la operación y los tipos de datos de sus argumentos (o parámetros). La implementación (o método) de la operación se especifica separadamente y puede modificarse sin afectar la interfaz. Los programas de aplicación de los usuarios pueden operar sobre los datos invocando a dichas operaciones a través de sus nombres y argumentos, sea cual sea la forma en la que se han implementado. Esto podría denominarse independencia entre programas y operaciones.

2.5. Persistencia, concurrencia y recuperación en BDOO.

Persistencia
Esta se refiere a la capacidad de manipular directamente los datos almacenados en una base de datos usando un lenguaje de programación orientado a objetos. Esto contrasta con una base de datos utilizada por SQL o una interfaz utilizada por ODBC o JDBC. Utilizando un objeto de base de datos significa que se puede tener un mayor rendimiento y se aminora la escritura de código. Con la persistencia la manipulación de objetos se realiza directamente por el lenguaje de programación de la misma manera que en la memoria, sin persistencia de objetos. Esto se logra mediante el uso inteligente de almacenamiento en caché.

Concurrencia
Los SMBDOO deben poder ser accesibles por múltiples usuarios. Cuando una aplicación está accesando a una sección de la base de datos, otras aplicaciones deben poder acceder a otras secciones de la base de datos. La concurrencia permite a los usuarios cooperar y colaborar en una aplicación. Los mecanismos de control de concurrencia son necesarios para reforzar las propiedades delas transacciones (ACID). Los modos básicos de control de concurrencia son: Modo Pesimista Modo optimista Modo mixto Modo semi-optimista. El modo pesimista obliga a una transacción a esperar a que se resuelva el conflicto que pueda o ponga en riesgo la concurrencia para dejarle continuar cuando el conflicto haya sido resuelto.

El modo optimista deje correr la transacción como si no ocurriera ningún conflicto y resuelve este al final del commit, generalmente se emplea usando estampas de tiempo y copias de los elementos de la transacción. El modo mixto combina diferentes controles de concurrencia a diferentes objetos y tipos de datas en una misma transacción. El modo semi-optimista es una variante del modo mixto que no detiene a la transacción hasta que esta termina. Los principales mecanismos de control de concurrencia son tres: Candados que prohíben accesos que puedan provocar conflictos de accesoEstampas de tiempo. - estas permiten impedir violaciones a los datos. Guardar múltiples versiones de los objetos de datos.

Recuperación
Con recuperación nos referimos al proceso de aplicación de consistencia después de que una transacción a abortado como resultado de fallas de hardware o problemas de comunicación. Las fallas del sistema, tanto de hardware como de software no deben repercutir en estados de inconsistencia de la base datos. La recuperación es la técnica que asegura que eso no ocurra. La recuperación puede ser total o parcial dependiendo de las circunstancias, de la recuperabilidad.

Unidad I. Fundamentos de bases de datos distribuidas

1.1. CONCEPTOS BÁSICOS DE BASES DE DATOS DISTRIBUIDAS

Una base de datos distribuida (BDD) es un conjunto de múltiples bases de datos lógicamente relacionadas las cuales se encuentran distribuidas en diferentes espacios lógicos y geográficos (pej. un servidor corriendo 2 máquinas virtuales) e interconectados por una red de comunicaciones. Dichas BDD tienen la capacidad de realizar procesamiento autónomo, esto permite realizar operaciones locales o distribuidas. Un sistema de Bases de Datos Distribuida (SBDD) es un sistema en el cual múltiples sitios de bases de datos están ligados por un sistema de comunicaciones de tal forma que, un usuario en cualquier sitio puede acceder los datos en cualquier parte de la red exactamente como si estos fueran accedidos de forma local.

Un sistema distribuido de bases de datos se almacena en varias computadoras. Los principales factores que distinguen un SBDD de un sistema centralizado son los siguientes:

  • Hay múltiples computadores, llamados sitios o nodos.
  • Estos nodos deben de estar comunicados por medio de algún tipo de red de comunicaciones para transmitir datos y órdenes entre los sitios.

Historia

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

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.

Evolución

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.

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 descentralizar 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 (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 podrían 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 libre.

Sistema manipulador de base de datos (DBMS)

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.

El procesamiento de bases de datos distribuidas es el proceso en el cual la ejecución de transacciones y la recuperación y actualización de los datos acontece a través de dos o más computadoras independientes, por lo general separadas geográficamente.

Las Bases de Datos Distribuidas, no son simplemente implementaciones distribuidas de bases de datos centralizadas, porque ellas permiten el diseño de sistemas que representan diferentes características de las tradicionales, de sistemas centralizados. Esto es por lo tanto útil para ver las características típicas de BDD. Los rasgos que caracterizan las BD tradicionales se aproximan al control centralizado, independencia de datos, reducción de redundancia, estructuras físicas complejas para acceso eficiente, integridad, recuperación control de concurrencia, privacidad y seguridad.

Los principales factores que distinguen un SBDD de un sistema centralizado son los siguientes:

  • Hay múltiples computadores, llamados sitios o nodos.
  • Estos sitios deben de estar comunicados por medio de algún tipo de red de comunicaciones para transmitir datos y órdenes entre los sitios
Un sistema de base de datos distribuidas es aquel en el que hay múltiples sitios de base de datos unidos por un sistema de comunicaciones, en forma tal que los datos en cualquier sitio son accesibles para los usuarios de otros sitios. Normalmente, cada sitio o nodo tiene un sistema completo de procesamiento de información, con su propia función de administración de datos, personal, usuarios, hardware y software. Inclusive una base de datos local, sistema de administración de base de datos y software de comunicaciones.

Lo mínimo que debe tener un sitio es memoria y procesador de comunicaciones. Los sitios por lo general están separados geográficamente y están unidos por un sistema de telecomunicaciones, aunque es posible tener un sistema distribuido y comunicado por medio de una red de área local dentro de un solo edificio o área pequeña. Se pretende que los usuarios no necesiten conocer la verdadera localización de los datos a que acceden y para ellos el sistema parece ser una base de datos local.

OBJETIVOS DE LAS B.D.D
  • Transparencia de ubicación. Permite a los usuarios tener acceso a los datos sin que tenga conocimiento de la ubicación de éstos.
  • Transparencia de duplicación. Para que la transparencia de duplicación sea posible, los administradores de transacciones deben traducir las solicitudes de procesamiento de transacción en acciones para el administrador de datos.
  • Transparencia de concurrencia. Cuando varias transacciones se ejecuten al mismo tiempo, los resultados de las transacciones no deberán afectarse.
  • Transparencia de fallas. Significa que a pesar de fallas las transacciones sean procesadas de un modo correcto. Frente a una falla, las transacciones deben ser atómicas, significa que se procesen todas o ninguna de ellas.
  • Localidad del procesamiento. Los datos se deben distribuir lo más cerca posible de las aplicaciones que los usan para maximizar la localidad del procesamiento, este principio responde a minimizar el acceso remoto a los datos.
  • Particionado de la Base de Datos. La base de datos se distribuye de modo que no haya solapamiento o duplicación de los datos mantenidos en las diferentes localidades, como no hay duplicaciones de los datos, se evitan los costos asociados con el almacenamiento y mantenimiento de datos redundantes.
  • Fragmentación de datos. Consiste en subdividir las relaciones y distribuirlas entre los sitios de la red, tiene como objetivo buscar formas alternativas de dividir una las instancias de relaciones en otras más pequeñas.

DISCIPLINAS DE ESTUDIO

Las principales disciplinas de estudio para conocer las bases son las siguientes: 

A) INGENIERÍA: Para conocer cono se desarrollan y que forma tendrán para implementarse
B) ÁLGEBRA: Busca establecer relaciones en base a funciones algebraicas
C) BASES DE DATOS: Buscan un adecuado funcionamiento de acuerdo a los principios de estas
D) REDES: Implementado en adecuado sistema para su funcionamiento sin concurrencia

1.2 Diseño de Bases de Datos Distribuidas

El problema de diseño de bases de datos distribuidos se refiere, en general, a hacer decisiones acerca de la ubicación de datos y programas a través de los diferentes sitios de una red de computadoras. La decisión de donde colocar a las aplicaciones tiene que ver tanto con el software del SMBDD como con las aplicaciones que se van a ejecutar sobre la base de datos.

Los pasos a seguir para diseñar una base de datos distribuida:

  1. Diseño del "esquema conceptual" el cual describe la base de datos integrada (esto es, todos los datos que son utilizados por las aplicaciones que tienen acceso a las bases de datos).
  2. Diseño "físico de la base de datos", esto es, mapear el esquema conceptual a las áreas de almacenamiento y determinar los métodos de acceso a las bases de datos.
  3. Diseño de la fragmentación, este se determina por la forma en que las relaciones globales se subdividen en fragmentos horizontales, verticales o mixtos.
  4. Diseño de la asignación de los fragmentos, esto se determina en la forma en que los fragmentos se mapean a las imágenes físicas, en esta forma, también se determina la solicitud de fragmentos.

ARQUITECTURA DE BASES DE DATOS DISTRIBUIDAS

Podemos destacar tres niveles principales según la visión y la función que realice el usuario sobre la base de datos:
  • Nivel Interno: es el nivel más cercano al almacenamiento físico de los datos. Permite escribirlos tal y como están almacenados en el ordenador. En este nivel se diseñan los archivos que contienen la información, la ubicación de los mismos y su organización, es decir se crean los archivos de configuración.
  • Nivel conceptual: En este nivel se representan los datos que se van a utilizar sin tener en cuenta aspectos como lo que representamos en el nivel interno.
  • Nivel externo: es el más cercano al usuario. En este nivel se describen los datos o parte de los datos que más interesan a los usuarios.
Estos tres niveles de visión de usuarios los proporcionan los sistemas gestores de base de datos.




1.3. Procesamiento de operaciones de actualización distribuida

Los sistemas cliente/servidor involucran varias computadoras conectadas a una red. Las computadoras que procesan programas de aplicaciones se conocen como clientes y las que procesan bases de datos se conocen como servidor.

Arquitectura Cliente Servidor

Un sistema cliente servidor puede tener varios servidores de procesamiento de bases de datos, cuando esto ocurre cada servidor debe procesar una base de datos distinta. Cuando dos o más servidores procesan una misma base de datos, el sistema no es considerado cliente servidor, más bien, es conocido como sistema de base de datos distribuido.

Funciones del cliente:

  • Administrar la interfaz de usuario.
  • Aceptar datos del usuario.
  • Procesar la lógica de la aplicación.
  • Generar las solicitudes para la base de datos.
  • Trasmitir las solicitudes de la base de datos al servidor.
  • Recibir los resultados del servidor.
  • Dar formatos a los resultados.

Funciones del servidor:

  • Aceptar las solicitudes de la base de datos de los clientes.
  • Procesar las solicitudes de los clientes.
  • Dar formato a los resultados y trasmitirlos al cliente.
  • Llevar a cabo la verificación de integridad.
  • Mantener los datos generales de la base de datos.
  • Proporcionar control de acceso concurrente.
  • Llevar a cabo la recuperación.
  • Optimizar el procesamiento de consulta/actualización.

1.4 Procesamiento de consultas distribuidas

El sistema debe de ser capaz de procesar consultas que hagan referencia a datos situados a mas de un nodo. Primeramente se debe de contar con heterogeneidad de los datos, para que puedan ser usados para formular consultas.

Tenemos los siguientes ejemplos:



Así como también necesitamos contar con:


  • Localización de los datos para generar reglas heuristicas
  • Descomposición de consultas en paralelo en cada nodo
  • Reducir la cantidad de datos a transferir en la red

ESTRATEGIAS DE PROCESAMIENTO DE CONSULTAS DE BASES DE DATOS DISTRIBUIDAS

Contamos con la estrategia de Re formulació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 atendidas con mayor velocidad.

OPTIMIZACIÓN DE CONSULTAS DISTRIBUIDAS

Para poder optimizar una consulta necesitamos tener claras las propiedades del algebra relacional para asegurar la re formulación de la consulta, al optimizar una consulta obtenemos los siguientes beneficios:

  • Minimizar costos
  • Reducir espacios de comunicaciones
  • Seguridad en envíos de información.

1.5. Manejo de Transacciones

Se considera el manejo de transacciones cuando un dispositivo móvil inicia una transacción hacia la base de datos o hacia un servidor fijo. La transacción puede ejecutarse en el servidor o en el dispositivo móvil.

Una transacción en un Sistema de Gestión de Bases de Datos (SGBD), es un conjunto de órdenes que se ejecutan formando una unidad de trabajo, es decir, en forma indivisible o atómica.Un SGBD se dice transaccional, si es capaz de mantener la integridad de los datos, haciendo que estas transacciones no puedan finalizar en un estado intermedio. Cuando por alguna causa el sistema debe cancelar la transacción, empieza a deshacer las órdenes ejecutadas hasta dejar la base de datos en su estado inicial (llamado punto de integridad), como si la orden de la transacción nunca se hubiese realizado.

Para esto, el lenguaje de consulta de datos SQL (Structured Query Language), provee los mecanismos para especificar que un conjunto de acciones deben constituir una transacción.BEGIN TRAN: Especifica que va a empezar una transacción.COMMIT TRAN: Le indica al motor que puede considerar la transacción completada con éxito.ROLLBACK TRAN: Indica que se ha alcanzado un fallo y que debe restablecer la base al punto de integridad.En un sistema ideal, las transacciones deberían garantizar todas las propiedades ACID; en la práctica, a veces alguna de estas propiedades se simplifica o debilita con vistas a obtener un mejor rendimiento.

Un ejemplo de transacción, Un ejemplo habitual de transacción es el traspaso de una cantidad de dinero entre cuentas bancarias. Normalmente se realiza mediante dos operaciones distintas, una en la que se decrementa el saldo de la cuenta origen y otra en la que incrementamos el saldo de la cuenta destino. Para garantizar la atomicidad del sistema (es decir, para que no aparezca o desaparezca dinero), las dos operaciones deben ser atómicas, es decir, el sistema debe garantizar que, bajo cualquier circunstancia (incluso una caída del sistema), el resultado final es que, o bien se han realizado las dos operaciones, o bien no se ha realizado ninguna.

Se debe tomar en cuenta: Desconexiones, movilidad, errores, fallas en el dispositivo móvil.

Se debe mantener la autonomía y la consistencia local del SMBD.

Los algoritmos dependen de:

  • Si el dispositivo está ejecutando la transacción (no, solo lectura, lectura y escritura)
  • Si se almacenaron los datos en disco.
  • Si el dispositivo móvil necesita datos que se encuentran en otros dispositivos móviles.