Unidad 4. Sistema de Gestión de Contenido

4.1 Definición, introducción y conceptos

Un sistema de gestión de contenidos (o CMS, del inglés Content Management System) es un programa que permite crear una estructura de soporte (framework) para la creación y administración de contenidos, principalmente en páginas web, por parte de los administradores, editores, participantes y demás usuarios.

Consiste en una interfaz que controla una o varias bases de datos donde se aloja el contenido del sitio web. El sistema permite manejar de manera independiente el contenido y el diseño. Así, es posible manejar el contenido y darle en cualquier momento un diseño distinto al sitio web sin tener que darle formato al contenido de nuevo, además de permitir la fácil y controlada publicación en el sitio a varios editores. Un ejemplo clásico es el de editores que cargan el contenido al sistema y otro de nivel superior (moderador o administrador) que permite que estos contenidos sean visibles a todo el público (los aprueba).

Definición

El gestor de contenido es una aplicación informática usada para crear, editar, gestionar y publicar contenido digital multimedia en diversos formatos. El gestor de contenidos genera páginas web dinámicas interactuando con el servidor web para generar la página web bajo petición del usuario, con el formato predefinido y el contenido extraído de la base de datos del servidor.

Esto permite gestionar, bajo un formato estandarizado, la información del servidor, reduciendo el tamaño de las páginas para descarga y reduciendo el coste de gestión del portal con respecto a un sitio web estático, en el que cada cambio de diseño debe ser realizado en todas las páginas web, de la misma forma que cada vez que se agrega contenido tiene que maquetarse una nueva página HTML y subirla al servidor web.

Otro conceptos

Entendido como un sistema de soporte a la gestión de contenidos; ya que, en realidad, son las estrategias de comunicación las que realmente llevan a gestionar contenidos y publicidad de forma efectiva; los sistemas informáticos pueden a lo sumo proporcionar las herramientas necesarias para la publicación en línea, o bien incluir servicios de soporte a la toma de decisiones por lo que a la gestión de contenidos se refiere.

El gestor de contenidos se aplica generalmente para referirse a sistemas de publicación, pudiendo subestimarse las funcionalidades de soporte y mantenimiento, en detrimento de las funcionalidades relacionadas con la optimización de los tiempos de publicación. La correcta implantación del sistema, con arreglo a las necesidades del cliente es necesaria, y es necesario entender el proyecto de un portal web en el seno de un proyecto de comunicación estructurado y bien planteado.

La elección de la plataforma correcta será vital para alcanzar los objetivos del cliente, ya que exentan particularidades diferenciales tanto en su adaptabilidad a esquemas gráficos como la posible integrabilidad de funcionalidades y extensiones adicionales.

El posicionamiento en buscadores está relacionado con el volumen de contenidos de un portal y con la forma en la que éste se presenta. Es importante tener eso en cuenta para la estructura del portal para garantizar un correcto posicionamiento orgánico.

4.2 Clasificación de contenidos

Los gestores de contenido se pueden clasificar según diferentes criterios:

Por sus características

Según el lenguaje de programación empleado, como por ejemplo Active Server Pages, Java, PHP, ASP.NET, Ruby On Rails, Python, PERL

Según la licencia: Código abierto o Software propietario

Por su uso y funcionalidad

Blogs; pensados para páginas personales.

Foros; pensados para compartir opiniones.

Wikis; pensados para el desarrollo colaborativo.

Enseñanza; plataforma para contenidos de enseñanza on-line.

Comercio electrónico; plataforma de gestión de usuarios, catálogo, compras y pagos.

Publicaciones digitales.

Difusión de contenido multimedia.

Propósito general.

4.3 Arquitectura de CMS

 Un sistema de administración de contenidos siempre funciona en el servidor web en el que esté alojado el portal. El acceso al gestor se realiza generalmente a través del navegador web, y se puede requerir el uso de FTP para subir contenido.

Cuando un usuario accede a una URL, se ejecuta en el servidor esa llamada, se selecciona el esquema gráfico y se introducen los datos que correspondan de la base de datos. La página se genera dinámicamente para ese usuario, el código HTML final se genera en esa llamada. Normalmente se predefinen en el gestor varios formatos de presentación de contenido para darle la flexibilidad a la hora de crear nuevos apartados e informaciones.

El Servidor Web, que será el único en contacto directo con los usuarios, aceptando peticiones de estos. Se encargue de atender las peticiones a recursos estáticos (imágenes, documentos HTML, CSS, JavaScript, etc.) y, en su caso, de redirigir las peticiones a recursos dinámicos (páginas JSP) hacia el Servidor de Aplicaciones. Como servidor web se selecciona a Apache HTTPD Server.

El Servidor de Aplicaciones, que alberga aplicaciones web dinámicas. Se encarga de recibir peticiones que redirige a la aplicación (también Llamada contexto) adecuada.

OpenCms se ejecuta dentro de este servidor como una aplicación web más. Como servidor de aplicaciones se selecciona a Apache Tomcat.

Las peticiones sobre contenidos llegan a OpenCms. Este procesa las reglas de negocio, y accede al repositorio para gestionar los contenidos necesarios y, de esta forma, llevar a cabo las funcionalidades requeridas.

Repositorio de contenidos alberga tantos contenidos estructurados, No estructurados, y reglas de negocio procesadas por el OpenCms.

4.4 Tipos de CMS

Por sus características:

·         Según el lenguaje de programación empleado, como por ejemplo Active Server Pages, Java, PHP, ASP.NET, Ruby On Rails, Python.

·         Según la licencia: Código abierto (como MySQL) o Software privativo.

Por su uso y funcionalidad:

·         Blogs: pensados para páginas personales (i.e. Blogger, WordPress, LifeType).

·         Foros: pensados para compartir opiniones (i.e. phpBB, Simple Machines Forum, MyBB).

·         Wikis: pensados para el desarrollo colaborativo (i.e. Wikipedia, MediaWiki).

·         Enseñanza: Sistemas de Gestión de Contenidos para el Aprendizaje o LCMS (i.e. ATutor, Sakai, Moodle).

·         Comercio electrónico: plataforma de gestión de usuarios, catálogo, compras y pagos (i.e. Magento, Opencart, Zen cart, osCommerce).

·         Publicaciones digitales: i.e. Public Knowledge Project con sus respectivos Open Journal System, Open Conference System, etc.

·         Difusión de contenido multimedia.

·         Y por último habría que añadir los pensados para realizar portales y sedes Web (i.e. Drupal, Joomla, Xoops, Plone).

A esta clasificación se le podrían añadir otras categorías, acudiendo a los apuntes de la asignatura Gestión de Contenidos:

·         Según la base de datos que utilizan: MySQL, Access, etc.

·         Según el entorno de trabajo: entorno Web o entorno “no Web” (de escritorio).

·         Según el estilo de uso:

o    Servicio comercial.

o    Servicio de comunidad (el soporte depende de la comunidad de desarrolladores y usuarios).

o    Hospedado (Software as as Service): Microsoft Office Live, Blogger, el mismo WordPress, etc.

4.5 Modelado y aplicación de CMS

Entre los sistemas de gestión documental más conocidos se encuentran los productos y aplicaciones de FileMaker, Knosys, el software CDS/ISIS desarrollado por la UNESCO o los productos de la compañía Inmagic, que cuenta con varias soluciones como DB/TextWorks, DB/Text WebPublisher o DBText Intranet Spider. Todos estos sistemas cuentan con pasarelas web para permitir las consultas, desde el navegador web, a las bases de datos creadas por ellos. Es de destacar también el software multilingüe de fuente abierta Greenstone Digital Libraries(http://www.greenstone.org/cgi-bin/library) que sirve para crear y distribuir colecciones de bibliotecas digitales.

También existen otra serie de herramientas muy sencillas y menos conocidas, algunas de ellas de libre disposición,  pero que cuentan con un gran potencial para gestionar documentos en diferentes morfologías de información: texto, imágenes, audio, etc. Las más potentes sirven también para gestionar sitios web y permiten clasificar los documentos, indizarlos, hacer tablas de contenido, realizar búsquedas, etc. Algunos incluyen hasta diccionarios y tesauros.

No cabe duda de que la forma hipertextual es en sí misma una herramienta para organizar y gestionar la información. A muchos de estos programas también se les denomina herramientas de autor, porque sirven para gestionar a pequeña escala nuestros propios hiperdocumentos.

Unidad 3. Sistemas 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.

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.

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.

3.2 Arquitectura de Sistema 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 ultimo los resultados de las consultas son combinados para construir los resultados de la consulta global. 

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 cuando los 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 NºMatricula,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 BD’s 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 del resto 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 BD 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.

Unidad 2. Sistemas de Bases de Datos Orientadas a Objetos

2.1 Modelo de Datos Orientados 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 procedimiento, 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 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 super-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 general.

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

SGBD de red. 

Los SGBD relacionales se basan en el modelo de datos de red. Los datos en el modelo de red se 

representan mediante colecciones de registros y las relaciones entre los datos se representan mediante 

enlaces, que se pueden ver como punteros. Los registros en la base de datos se organizan como 

colecciones de grafos dirigidos. En la figura se presenta un ejemplo de base de datos en red. 

SGBD jerárquicos. 

Los SGBD relacionales se basan en el modelo de datos jerárquico. El modelo jerárquico es similar al 

modelo de redes, en el sentido en que los datos y las relaciones entre los datos se representan mediante 

registros y enlaces, respectivamente. Éste se diferencia del modelo de redes en que los registros se 

organizan como colecciones de árboles en lugar de grafos dirigidos. En la siguiente figura se presenta un 

ejemplo de base de datos jerárquica. 

Modelo de datos relacionales. 

 Basados en el modelo relacional, los datos se describen como relaciones que se suelen representar 

como tablas bidimensionales consistentes en filas y columnas. Cada fila (tupla, en terminología 

relacional) representa una ocurrencia. Las columnas (atributos) representan propiedades de las filas. 

Cada tupla se identifica por una clave primaria o identificadora. 

Modelo orientados a objetos. 

Una de las novedades más prometedoras y más desarrolladas comercialmente de los nuevos SGBD, 

son los basados en un nuevo modelo de datos conocido como modelo orientado a objetos. La 

orientación a objetos es un paradigma que no se aplica sólo al desarrollo de SGBD sino, en general, al 

desarrollo de sistemas de información.

2.1.3 Productos

SGBD libres

MySQL Licencia Dual

PostgreSQL

SQLite

DB2 Express-C

Apache Derby

SGBD no libres

Advantage Database

dBase

FileMaker

Fox Pro

IBM DB2 Universal Database (DB2 UDB)

IBM Informix

Interbase de CodeGear, filial de Borland

MAGIC

Microsoft Access

Microsoft SQL Server

NexusDB

Open Access

Oracle

Paradox

PervasiveSQL

Progress (DBMS)

Sybase ASE

Sybase ASA

Sybase IQ

WindowBase

IBM IMS Base de Datos Jerárquica

CA-IDMS

SGBD no libres y gratuitos

Microsoft SQL Server Compact Edition Basica

Sybase ASE Express Edition para Linux

Oracle Express Edition 10

2.2 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 ultima versión, ODMG 3.0, apareció en enero de 2000.

2.3 Identidad y Estructura de Objetos

Un objeto es una cosa tangible, algo a que se puede aprehender intelectualmente o algo hacia lo que se puede dirigir una acción o pensamiento.

Un objeto representa un item individual e identificable, o una entidad real o abstracta, con un papel definido en el dominio del problema

Un objeto tiene:

Estado

Comportamiento

Identidad

La estructura y el comportamiento de objetos similares se definen en sus clases comunes. El término objeto y ejemplo (instance) de una clase son intercambiables.

Identidad de un objeto

Identidad es la propiedad de un objeto que lo lleva a distinguirse de otros.

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. Así dibuja tendrá un único nombre y podrá emplearse indiferentemente sobre cualquier figura.
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 dentrode 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 selogra 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 halla 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 acceso Estampas 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 sistemas, 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 1. Sistemas de Bases de Datos Distribuidas

1.1 Concepto de Base de Datos Distribuida

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.  


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.

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

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.

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 esta 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.