Unidad 4 SISTEMA DE GESTION DE CONTENIDO

4.1 Definición, introducción y conceptos

Definición

CMS son las siglas de Content Management System, que se traduce directamente al español como Sistema Gestor de Contenidos. Como su propio nombre indica, es un sistema que nos permite gestionar contenidos. En líneas generales, un CMS  permitiría administrar contenidos en un medio digital y para el caso particular que nos ocupa, un CMS permitiría gestionar los contenidos de una web.

Dicho de otra forma, un CMS  es una herramienta que permite a un editor crear, clasificar y publicar cualquier tipo de información en una página web. Generalmente los CMS trabajan contra una base de datos, de modo que el editor simplemente actualiza una base de datos, incluyendo nueva información o editando la existente.

Introducción

Un CMS es un Gestor de Contenidos (Counter Management Systems), una herramienta muy flexible que esta centrada especialmente en la gestión de contenidos mediante la web.
En el transcurso de la web 1.0 a la web 2.0 se hizo patente la necesidad de herramientas que permitiesen a los usuarios de internet poder publicar contenidos sin necesidad de tener conocimientos de html, css, lenguajes de programación, o bases de datos. Uno de los elementos que definen la web 2.0 es la participación ciudadana en la creación de dichos contenidos, y los gestores de contenidos son las herramientas que han logrado esta realidad.


Conceptos

Creación de contenido

Un CMS aporta herramientas para que los creadores sin conocimientos técnicos en páginas web puedan concentrarse en el contenido. Lo más habitual es proporcionar un editor de texto WYSIWYG, en el que el usuario ve el resultado final mientras escribe, al estilo de los editores comerciales, pero con un rango de formatos de texto limitado. Esta limitación tiene sentido, ya que el objetivo es que el creador pueda poner énfasis en algunos puntos, pero sin modificar mucho el estilo general del sitio web.

Gestión de contenido

Los documentos creados se depositan en una base de datos central donde también se guardan el resto de datos de la web, cómo son los datos relativos a los documentos (versiones hechas, autor, fecha de publicación y caducidad, etc.), datos y preferencias de los usuarios, la estructura de la web, etc.

Publicación

Una página aprobada se publica automáticamente cuando llega la fecha de publicación, y cuando caduca se archiva para futuras referencias. En su publicación se aplica el patrón definido para toda la web o para la sección concreta donde está situada, de forma que el resultado final es un sitio web con un aspecto consistente en todas sus páginas.

Presentación

Un CMS puede gestionar automáticamente la accesibilidad del web, con soporte de normas internacionales de accesibilidad como WAI, y adaptarse a las preferencias o necesidades de cada usuario.

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.

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.

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:

• Servicio comercial.
• Servicio de comunidad (el soporte depende de la comunidad de desarrolladores y usuarios).
• 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.

Con la aparición de la llamada Web 2.0, han proliferado los Sistemas de gestión de contenidos o Content Management System  (CMS). Estas herramientas permiten la creación y administración de contenidos de páginas web. Se trata de una interfaz que controla una o varias bases de datos donde se aloja el contenido del sitio web. Hay gestores para páginas web,foros, blogs, wikis, etc. Estos sistemas permiten tratar de manera separada el diseño del contenido. Una relación exhaustiva de estas herramientas se ofrece en esta tesis en Sistemas de Gestión de Hipertextos para la Web 2.0.

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.

Base de datos federada

Un sistema de bases de datos federadas es una colección de sistemas de bases de datos cooperativos y autónomos [Bhavani99]. En un sistema federado los usuarios tienen acceso a los datos, de los distintos sistemas, a través de una interfaz común sin embargo, no existe un esquema global que describa a todos los datos de las distintas bases de datos, en su lugar hay varios esquemas unificados, cada uno describiendo porciones de bases de datos y archivos para el uso de cierta clase de usuarios [Larson90].

AUTONOMÍA DE BASES DE DATOS.

1.    Diseño: modelo, lenguaje, implementación.

2.    Comunicación: como, cuando se responde a otros sistemas.

3.    Ejecución: Criterio a seguir en la toma de decisiones.

4.    Asociación: decisión de que datos se comparten y a quien.

 PROPIEDADES

•    Este tipo de manejadores, tiene un manejo transparente para los usuarios.
• 
  
•   Se aprecia como una sola base de datos. A esto se le conoce como ínter operar y existen tres formas: Distribuidas, federadas o multibase.
• 
  
•     El sistema esta conformado por un conjunto de bases de datos heterogéneas. Esto significa que pueden o no tener diferentes sistemas operativos, diferente equipo de computo(hardware), diferentes manejadores de bases de datos, diferente modelo de datos(J, red, Relacional, orientada a objetos), diferente estructura de datos.
• 
  
•     Las bases de datos que participan en la BDF mantienen su autonomía.  Esto quiere decir que cada elemento de la federación decide con quien, que y como compartir sus datos, además de que cada una cuenta con su respectivo diseño de acuerdo con las necesidades del usuario.
• 
  
•    El MBDF(Manejador de Bases de Datos Federadas) recibe una consulta sencilla y este a su vez la descompone en varia consultas parciales.
• 
  
•     El MBDF deberá tener una optimizador de recursos para aprovechar correctamente todos los componentes.
• 
  
• 
  
•    Pueden ser físicamente distribuidas en diferentes lugares e incluso en lugares muy lejanos.

Base de datos NO federado

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

Los DBMS individuales son totalmente autónomos (en BD distribuidas o no). No tienen idea de la existencia del otro o cómo hablar el uno al otro .

BDF

Son vistas unificadas de bases de datos independientes aparentan ser una sola base de datos, pero son una colección de sistemas de bases de datos independientes, cooperativos, heterogéneos, que son autónomos y que permiten compartir todos o algunos de sus datos.

Se dice que son heterogéneos debido a que los sistemas de bases de datos pueden tener cualquier arquitectura. 

Autonomía es que cada sistema de bases de datos funcione por sí mismo y de forma local. 

Está formado por varios gestores de bases de datos que pueden ser para bases de datos centralizadas o distribuidas, además pueden ser también sistemas de bases de datos federados.

Problemas:

• Incompatibilidad entre sistemas de consulta diferentes.

• Diferente codificación en los componentes del SGBD.

• Dificultades para establecer un control de las concurrencias en distintas transacciones.

GCS

En DDBMS la GCS define la visión conceptual de la base de datos

°En DMulti-DBMS: - el GCS representa sólo la parte o parte de la base de datos local que debe ser compartida.

°Algunos C / SDBMS ejemplo SYBASE admite consultas y actualizaciones a muchos servidores de bases de datos.

un sistema multi-base de datos es una colección interconectada de bases de datos autónomas.

3.3 Procesamiento de operaciones de actualización

Una transacción es una unidad lógica de trabajo, la cual no necesariamente consta de una sola operación en la base de datos; más bien, es en general una secuencia de varias de esas operaciones mediante la cual un estado consistente de la base de datos se transforma en otro estado consistente, sin conservar por fuerza la consistencia en todos los puntos intermedios. El punto importante aquí es asegurar que la base de datos regresa a un estado consistente al fin de la ejecución de una transacción. Una transacción es también la invocación a un procedimiento remoto (RPC) que ejecuta un conjunto de operaciones sobre una base de datos bajo el principio de todo o nada.

El concepto fundamental aquí es la noción de "ejecución consistente" o "procesamiento confiable" asociada con el concepto de una consulta. El concepto transacción es usado dentro del dominio de la base de datos como una unidad básica de cómputo consistente y confiable

Una transacción posee cuatro propiedades fundamentales

Atomicidad.

Una Transacción es una unidad de trabajo indivisible; la totalidad de sus acciones son un éxito un fracaso ("todo o nada"). Consistencia. Después de ejecuta una Transacción debe dejar al sistema en estado correcto o debe abortarlo. Si la Transacción no puede alcanzar un estado final debe regresar al sistema a su estado original. Aislamiento. El comportamiento de una Transacción no se ve afectado por el hecho de que otras Transacciones puedan estar ejecutándose de manera concurrente; dicho de otra manera, una Transacción no puede revelar sus resultados a otras Transacciones concurrentes antes de su commit. La Transacción debe serializar todos los accesos a recursos compartidos y garantizar que ningún programa concurrente interferirá con sus operaciones respectivas.

Durabilidad.

 Los efectos de una Transacción son permanentes después de su grabación. Sus cambios deben sobrevivir a fallas del sistema. (Persistencia). BITÁCORA La operación ROLLBACKesta basada en el uso de una ?bitacora?. El DBMS (Sistema Manejador de Bases de Datos) mantiene una bitácora o diario en cinta o en disco (mas comúnmente), en el cual se registran los detalles de todas las operaciones de actualización, en particular, los valores inicial y final del objeto modificado. Por tanto, si resulta necesario anular alguna modificación específica, el sistema puede utilizar la entrada correspondientede la bitácora para restaurar el valor original del objeto restaurado. PUNTO DE SINCRONIZACION Las operaciones COMMIT y ROLLBACK establecen lo que se le conoce como punto de sincronización lo cual representa el límite entre dos transacciones consecutivas, o el final de una unidad lógica de trabajo, y por tanto al punto en el cual la base de datos esta (o debería estar) en un estado de consistencia. Las únicas operaciones que establecen un punto de sincronización son COMMIT, ROLLBACK y el inicio de una programa. Cuando se establece un punto de sincronización:

Se comprometen o anulan todas las modificaciones realizadas por el programa desde el punto de sincronización anterior. Se pierde todo posible posicionamiento en la base de datos. Se liberan todos los registros bloqueados.

Es importante advertir que COMMIT y ROLLBACK terminan las transacción, no el programa

3.4 Procesamiento de Consultas

OBJETIVOS DEL PROCESAMIENTO DE CONSULTAS

Los objetivos del procesamiento de consultas son transformar una consulta escrita en un lenguaje de alto nivel, normalmente SQL, en una estrategia de ejecución correcta y eficiente expresada en un lenguaje de bajo nivel, por ejemplo, el álgebra relacional, y ejecutar dicha estrategia para extraer los datos solicitados.

 ¿En qué sentido difiere el procesamiento de consultas en los sistemas relacionales del procesamiento de lenguajes de consultas de bajo nivel para sistemas de red jerárquicos?

 En los sistemas de bases de datos en red y jerárquicos de primera generación, el sistema de consulta procedimental de bajo nivel está generalmente incrustado en un lenguaje de programación de alto nivel tal como COBOL, y es responsabilidad del programador seleccionar la estrategia de ejecución más apropiada.

 FASES DEL PROCESAMIENTO DE CONSULTAS

 El procesamiento de consultas puede dividirse en cuatro fases principales: Descomposición. Optimización. Generación de código. Ejecución.

La descomposición de consultas transforma una consulta d alto nivel en una consulta de álgebra relacional y comprueba que dicha consulta sea sintáctica y semánticamente correcta. Las etapas típicas de la descomposición de consultas son:

 ETAPAS DE LA DESCOMPOSICIÓN DE CONSULTAS

 Análisis Normalización. Análisis semántico. Simplificación. Reestructuración de la consulta.

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 BASE DE DATOS ORIENTADAS A OBJETOS

2.1 Modelo de datos orientados a objetos

La existencia de problemas para representar cierta información y modelar ciertos aspectos del "mundo real", puesto que los modelos clásicos permiten representar gran cantidad de datos, pero las operaciones y representaciones que se pueden realizar sobre ellos son bastante simples.

El paso del modelo de objetos al modelo relacional genera dificultades que en el caso no surgen ya que el modelo es el mismo.Por lo tanto, las bases de datos orientadas a objetos surgen básicamente para tratar de paliar las deficiencias de los modelos anteriores y para proporcionar eficiencia y sencillez a las aplicaciones.

Las debilidades y limitaciones de los Sistema Gestor de Bases de Datos Orientadas a Objetos son:

• Pobre representación de las entidades del "mundo real".
• Sobrecarga y poca riqueza semánticas.
• Soporte inadecuado para las restricciones de integridad y empresariales
• Estructura de datos homogénea
• Operaciones limitadas
• Dificultades para gestionar las consultas re cursivas
• Des adaptación de impedancias

Problemas asociados a la concurrencia, cambios en los esquemas y el inadecuado acceso navegacional

No ofrecen soporte para tipos definidos por el usuario (sólo dominios)Mientras que las necesidades de las aplicaciones actuales con respecto a las bases de datos son:

• Soporte para objetos complejos y datos multimedia
• Identificadores únicos
• Soporte a referencias e interrelaciones
• Manipulación navegacional y de conjunto de registros
• Jerarquías de objetos o tipos y herencia
• Integración de los datos con sus procedimientos asociados
• Modelos extensibles mediante tipos de datos definidos por el usuario
• Gestión de versiones
• Facilidades de evolución
• Transacciones de larga duración
• Interconexión e interoperabilidad

Debido a las limitaciones anteriormente expuestas, su uso es más ventajoso si se presenta en alguno de los siguientes escenarios:

Un gran número de tipos de datos diferentes

Un gran número de relaciones entre los objetos

Objetos con comportamientos complejos

Se puede encontrar este tipo de complejidad acerca de tipos de datos, relaciones entre objetos y comportamiento de los objetos principalmente en aplicaciones de ingeniería, manufacturación, simulaciones, automatización de oficina y en numerosos sistemas de información. No obstante, las BDOO no están restringidas a estas áreas. Ya que al ofrecer la misma funcionalidad que su precursoras relacionales, el resto de campos de aplicación tiene la posibilidad de aprovechar completamente la potencia que las BDOO ofrecen para modelar situaciones del mundo real.

2.1.1 Caracteristicas de SGBDOO

Las características de un SGBDOO son:

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. 

2.1.3 PRODUCTOS

SGBD libres

• MySQL Licencia Dual, depende el uso (no se sabe hasta cuando, ya que la compro Oracle). Sin embargo, existen 2 versiones: una gratuita que sería equivalente a la edicion “express” SQL server de Windows y otra más completa de pago, ese pago se haría en la licencia de ella ya que permitiría usarse en otras distribuciones sin usar la licencia GNU.
• PostgreSQL (http://www.postgresql.org Postgresql) Licencia 
• BSDFirebird basada en la versión 6 de InterBase, Initial Developer’s PUBLIC LICENSE Version 1.0.
• SQLite (http://www.sqlite.org SQLite) Licencia Dominio PúblicoDB2 Express-C (http://www.ibm.com/software/data/db2/express/)
• Apache Derby (http://db.apache.org/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 (edición gratuita para Linux)
• Oracle Express Edition 10

2.2 Estandar 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.

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 unico. 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 unobjeto 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).

2.4 Encapsulamiento, Herencia y Polimorfismo en BDOO

Encapsulamiento

El encapsulamiento consiste en unir en la Clase las características y comportamientos, esto es, las variables y métodos. Es tener todo esto es una sola entidad. En los lenguajes estructurados esto era imposible. Es evidente que el encapsulamiento se logra gracias a la abstracción y el ocultamiento 

La utilidad del encapsulamiento va por la facilidad para manejar la complejidad, ya que tendremos a las Clases como cajas negras donde sólo se conoce el comportamiento pero no los detalles internos, y esto es conveniente porque nos interesará será conocer qué hace la Clase pero no será necesario saber cómo lo hace.

Herencia 

 A través de ella los diseñadores pueden crear nuevas clases partiendo de una clase o de una jerarquía de clases preexistente (ya comprobadas y verificadas) evitando con ello el rediseño, la modificación y verificación de la parte ya implementada. La herencia facilita la creación de objetos a partir de otros ya existentes e implica que una subclase obtiene todo el comportamiento (métodos) y eventualmente los atributos (variables) de su superclase.

Es la relación entre una clase general y otra clase más específica. Por ejemplo: Si declaramos una clase párrafo derivada de una clase texto, todos los métodos y variables asociadas con la clase texto, son automáticamente heredados por la subclase párrafo.

La herencia es uno de los mecanismos de los lenguajes de programación orientada a objetos basados en clases, por medio del cual una clase se deriva de otra de manera que extiende su funcionalidad. La clase de la que se hereda se suele denominar clase base, clase padre, superclase, clase ancestro (el vocabulario que se utiliza suele depender en gran medida del lenguaje de programación).

En los lenguajes que cuentan con un sistema de tipos fuerte y estrictamente restrictivo con el tipo de datos de las variables, la herencia suele ser un requisito fundamental para poder emplear el Polimorfismo, al igual que un mecanismo que permita decidir en tiempo de ejecución qué método debe invocarse en respuesta a la recepción de un mensaje, conocido como enlace tardío (late binding) o enlace dinámico (dynamic binding).

Polimorfismo

se refiere a la propiedad por la que es posible enviar mensajes sintácticamente iguales a objetos de tipos distintos. El único requisito que deben cumplir los objetos que se utilizan de manera polimórfica es saber responder al mensaje que se les envía.

La apariencia del código puede ser muy diferente dependiendo del lenguaje que se utilice, más allá de las obvias diferencias sintácticas.

En lenguajes basados en clases y con un sistema de tipos de datos fuerte (independientemente de si la verificación se realiza en tiempo de compilación o de ejecución), es posible que el único modo de poder utilizar objetos de manera polimórfica sea que compartan una raíz común, es decir, una jerarquía de clases, ya que esto proporciona la compatibilidad de tipos de datos necesaria para que sea posible utilizar una misma variable de referencia (que podrá apuntar a objetos de diversas subclases de dicha jerarquía) para enviar el mismo mensaje (o un grupo de mensajes) al grupo de objetos que se tratan de manera polimórfica.

No obstante, algunos lenguajes de programación (Java, C++) permiten que dos objetos de distintas jerarquías de clases respondan a los mismos mensajes, a través de las denominadasinterfaces (esta técnica se conoce como composición de objetos). Dos objetos que implementen la misma interfaz podrán ser tratados de forma idéntica, como un mismo tipo de objeto, el tipo definido por la interfaz. Así, distintos objetos podrán intercambiarse en tiempo de ejecución –siempre que sean del mismo tipo–, y además con dependencias mínimas entre ellos. Por estos motivos se considera un buen principio de diseño en programación orientada a objetos el favorecer la composición de objetos frente a la herencia de clases.¹

En Java las interfaces se declaran mediante la palabra clave "interfaces" Estas se utilizan para lograr la necesaria concordancia de tipos que hace posible el polimorfismo, también como un contrato que debe cumplir cualquier clase que implemente una cierta interfaz, y como una forma de documentación para los desarrolladores. A veces, en la literatura específica sobre Java se habla de "herencia y polimorfismo de interfaces", lo que no concuerda con los conceptos de la programación orientada a objetos porque una clase que implementa una interfaz sólo obtiene su tipo de datos y la obligación de implementar sus métodos, no copia comportamiento ni atributos. Esta terminología puede llevar a confusión, puesto que en Java a menudo se utiliza la mal llamada "herencia de interfaces" para dotar a una clase de uno o varios tipos adicionales, lo que unido a la composición, evite la necesidad de la herencia múltiple y favorezca una utilización más amplia del polimorfismo.

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 unobjeto de base de datos significa que se puede tener un mayor rendimiento y se aminora laescritura 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 BASE DE DATOS DISTRIBUIDAS

1.1 Concepto de base de datos distribuidas

Bases de Datos Distribuidas Definición: 

Consiste en una colección de sitios, conectados por medio de algún tipo de red de comunicación, en el cual Cada sitio es un sistema de BD completo por derecho propio, pero Los sitios ha acordado trabajar juntos, a fin de que un usuario de cualquier sitio pueda acceder a los datos desde cualquier lugar de la red, exactamente como si los datos estuvieran guardados en el propio sitio del usuario.

VENTAJAS

• Refleja una estructura organizacional - los fragmentos de la base de datos se ubican en los departamentos a los que tienen relación.
• - los fragmentos de la base de datos se ubican en los departamentos a los que tienen relación.
• Autonomía local - un departamento puede controlar los datos que le pertenecen.
• Disponibilidad - un fallo en una parte del sistema solo afectará a un fragmento, en lugar de a toda la base de datos.
• Rendimiento - los datos generalmente se ubican cerca del sitio con mayor demanda, también los sistemas trabajan en paralelo, lo cual permite balancear la carga en los servidores.
• Economía - es más barato crear una red de muchas computadoras pequeñas, que tener una sola computadora muy poderosa.
• Modularidad - se pueden modificar, agregar o quitar sistemas de la base de datos distribuida sin afectar a los demás sistemas (módulos).

DESVENTAJAS

• Complejidad - Se debe asegurar que la base de datos sea transparente, se debe lidiar con varios sistemas diferentes que pueden presentar dificultades únicas. El diseño de la base de datos se tiene que trabajar tomando en cuenta su naturaleza distribuida, por lo cual no podemos pensar en hacer joins que afecten varios sistemas.
• Economía - la complejidad y la infraestructura necesaria implica que se necesitará una mayor mano de obra.
• Seguridad - se debe trabajar en la seguridad de la infraestructura así como cada uno de los sistemas.
• Integridad - Se vuelve difícil mantener la integridad, aplicar las reglas de integridad a través de la red puede ser muy caro en términos de transmisión de datos.
• Falta de experiencia - las bases de datos distribuidas son un campo relativamente nuevo y poco común por lo cual no existe mucho personal con experiencia o conocimientos adecuados.
• Carencia de estándares - aún no existen herramientas o metodologías que ayuden a los usuarios a convertir un DBMS centralizado en un DBMS distribuido.
• Diseño de la base de datos se vuelve más complejo - además de las dificultades que generalmente se encuentran al diseñar una base de datos, el diseño de una base de datos distribuida debe considerar la fragmentación, replicación y ubicación de los fragmentos en sitios específicos.

1.2 Diseño de Bases de Datos Distribuidas

El diseño de un sistema de base de datos distribuido implica la toma de decisiones sobre la ubicación de los programas que accederán a la base de datos y sobre los propios datos que constituyen esta última.

A lo largo de los diferentes puestos que configuren una red de ordenadores. La ubicación de los programas, a priori, no debería suponer un excesivo problema dado que se puede tener una copia de ellos en cada máquina de la red (de hecho, en este documento se asumirá que así es). Sin embargo, cuál es la mejor opción para colocar los datos: en una gran máquina que albergue a todos ellos, encargada de responder a todas las peticiones del resto de las estaciones - sistema de base de datos centralizado -, o podríamos pensar en repartir las relaciones, las tablas, por toda la red. En el supuesto que nos decantásemos por esta segunda opción, ¿qué criterios se deberían seguir para llevar a cabo tal distribución? ¿Realmente este enfoque ofrecerá un mayor rendimiento que el caso centralizado? ¿Podría optarse por alguna otra alternativa? En los párrafos sucesivos se tratará de responder a estas cuestiones.

Tradicionalmente se ha clasificado la organización de los sistemas de bases de datos distribuidos sobre tres dimensiones: el nivel de compartición, las características de acceso a los datos y el nivel de conocimiento de esas características de acceso (vea la figura 1). El nivel de compartición presenta tres alternativas: inexistencia, es decir, cada aplicación y sus datos se ejecutan en un ordenador con ausencia total de comunicación con otros programas u otros datos; se comparten sólo los datos y no los programas, en tal caso existe una réplica de las aplicaciones en cada máquina y los datos viajan por la red; y, se reparten datos y programas, dado un programa ubicado en un determinado sitio, éste puede solicitar un servicio a otro programa localizado en un segundo lugar, el cual podrá acceder a los datos situados en un tercer emplazamiento. Como se comentó líneas atrás, en este caso se optará por el punto intermedio de compartición.

Respecto a las características de acceso a los datos existen dos alternativas principalmente: el modo de acceso a los datos que solicitan los usuarios puede ser estático, es decir, no cambiará a lo largo del tiempo, o bien, dinámico. El lector podrá comprender fácilmente la dificultad de encontrar sistemas distribuidos reales que puedan clasificarse como estáticos. Sin embargo, lo realmente importante radica, estableciendo el dinamismo como base, cómo de dinámico es, cuántas variaciones sufre a lo largo del tiempo. Esta dimensión establece la relación entre el diseño de bases de datos distribuidas y el procesamiento de consultas.

La tercera clasificación es el nivel de conocimiento de las características de acceso. Una posibilidad es, evidentemente, que los diseñadores carezcan de información alguna sobre cómo los usuarios acceden a la base de datos. Es una posibilidad teórica, pero sería muy laborioso abordar el diseño de la base de datos con tal ausencia de información. Lo más práctico sería conocer con detenimiento la forma de acceso de los usuarios o, en el caso de su imposibilidad, conformarnos con una información parcial de ésta.

El problema del diseño de bases de datos distribuidas podría enfocarse a través de esta trama de opciones. En todos los casos, excepto aquel en el que no existe compartición, aparecerán una serie de nuevos problemas que son irrelevantes en el caso centralizado.

A la hora de abordar el diseño de una base de datos distribuida podremos optar principalmente por dos tipos de estrategias: la estrategia ascendente y la estrategia descendente. Ambos tipos no son excluyentes, y no resultaría extraño a la hora de abordar un trabajo real de diseño de una base de datos que se pudiesen emplear en diferentes etapas del proyecto una u otra estrategia. La estrategia ascendente podría aplicarse en aquel caso donde haya que proceder a un diseño a partir de un número de pequeñas bases de datos existentes, con el fin de integrarlas en una sola. En este caso se partiría de los esquemas conceptuales locales y se trabajaría para llegar a conseguir el esquema conceptual global. Aunque este caso se pueda presentar con facilidad en la vida real, se prefiere pensar en el caso donde se parte de cero y se avanza en el desarrollo del trabajo siguiendo la estrategia descendente. La estrategia descendente debería resultar familiar a la persona que posea conocimientos sobre el diseño de bases de datos, exceptuando la fase del diseño de la distribución. Pese a todo, se resumirán brevemente las etapas por las que se transcurre.

Todo comienza con un análisis de los requisitos que definirán el entorno del sistema en aras a obtener tanto los datos como las necesidades de procesamiento de todos los posibles usuarios del banco de datos. Igualmente, se deberán fijar los requisitos del sistema, los objetivos que debe cumplir respecto a unos grados de rendimiento, seguridad, disponibilidad y flexibilidad, sin olvidar el importante aspecto económico. Como puede observarse, los resultados de este último paso sirven de entrada para dos actividades que se realizan de forma paralela. El diseño de las vistas trata de definir las interfaces para el usuario final y, por otro lado, el diseño conceptual se encarga de examinar la empresa para determinar los tipos de entidades y establecer la relación entre ellas. Existe un vínculo entre el diseño de las vistas y el diseño conceptual. El diseño conceptual puede interpretarse como la integración de las vistas del usuario, este aspecto es de vital importancia ya que el modelo conceptual debería soportar no sólo las aplicaciones existentes, sino que debería estar preparado para futuras aplicaciones. En el diseño conceptual y de las vistas del usuario se especificarán las entidades de datos y se determinarán las aplicaciones que funcionarán sobre la base de datos, así mismo, se recopilarán datos estadísticos o estimaciones sobre la actividad de estas aplicaciones. Dichas estimaciones deberían girar en torno a la frecuencia de acceso, por parte de una aplicación, a las distintas relaciones de las que hace uso, podría afinarse más anotando los atributos de la relación a la que accede. Desarrollado el trabajo hasta aquí, se puede abordar la confección del esquema conceptual global. Este esquema y la información relativa al acceso a los datos sirven de entrada al paso distintivo: el diseño de la distribución. El objetivo de esta etapa consiste en diseñar los esquemas conceptuales locales que se distribuirán a lo largo de todos los puestos del sistema distribuido. Sería posible tratar cada entidad como una unidad de distribución; en el caso del modelo relacional, cada entidad se corresponde con una relación. Resulta bastante frecuente dividir cada relación en subrelaciones menores denominadas fragmentos que luego se ubican en uno u otro sitio.

De ahí, que el proceso del diseño de la distribución conste de dos actividades fundamentales: la fragmentación y la asignación. El último paso del diseño de la distribución es el diseño físico, el cual proyecta los esquemas conceptuales locales sobre los dispositivos de almacenamiento físico disponibles en los distintos sitios. Las entradas para este paso son los esquemas conceptuales locales y la información de acceso a los fragmentos. Por último, se sabe que la actividad de desarrollo y diseño es un tipo de proceso que necesita de una motorización y un ajuste periódicos, para que si se llegan a producir desviaciones, se pueda retornar a alguna de las fases anteriores. 

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

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

BD CENTRALIZADA

BD DISTRUIBUIDA

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 envios de informacion.

1.5 Manejo de Transacciones

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ónUn 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.