Versant es un sistema gestor de base de datos orientada a objetos (SGBDOO) desarrollado por Versant Corporation.
Requerimientos del Sistema Lenguajes: C++, Java Sistemas Operativos: Microsoft Windows 2000, XP, 2003 Sun Solaris 2.9, 2.10 IBM AIX 5.1, 5.3 HP-UX 11i Red Hat RHEL 3.0, 4.0 JDK 1.4, 1.5
Objetos
Tipos de Objetos Objeto genérico Objeto Instancia: Objeto que almacena datos Objeto Clase: Cuando se crea una clase Versant crea un objeto clase, o objeto esquema, que almacena la definición de tipos en la base de datos Objeto Versionado: Objeto que guarda las diferentes versiones, se llega desde un objeto instancia. Objeto transitorio: Solo existe cuando el programa que lo creó este en ejecución Objeto persistente: Un objeto que existe aunque el programa que lo creó no este en ejecución Objeto estándar: Objeto creado con el operador new de C++/Versant Objeto embebido: Objeto que es un atributo de otro objeto. Objeto inteligente: Objeto que selecciona automáticamente la versión correcta basándose en una configuración previa.
Tipos Predefinidos Vstr: Permite almacenar uno o varios elementos básicos de tamaño variable Link: Almacena una referencia a otro objeto Link Vstr: Almacena varias referencias a objetos C/Versant: List: Almacena varios elementos de forma ordenada C++/Versant: Bi-Link: Almacena una referencia bi-direccional Bi-Link Vstr: Almacena uno o varias referencias bi-direccionales Array: Almacena una colección de elementos ordenados que son accedidos por un índice numérico Set: Almacena una colección desordenada de elementos únicos Dictionary: Almacena una colección que mapea claves de valores List: Almacena varios elementos de forma ordenada Date / Time: Tipos para almacenamiento de Fechas y Horas
Versant también tiene facilidades para poder usar tipos definidos por terceras personas a través de librerías
Estado de los Objetos Transient/Persistent: A pesar de que los objetos se usan igual si están en modo Transient o en Persistent, Versant solo escribe en la base de datos si el objeto es Persistent Lock: El objeto puede tener un cerrojo establecido. Dirty: Cuando el objeto se cambia se marca como sucio, esto significa que será actualizado en el próximo commit Versioned: Mantiene todas las versiones que tenga un objeto. No se sobrescribe, se crea una nueva versión Configuration: Se pueden agrupar los objetos en configuraciones y luego acceder a toda la configuración a través de un smart object Checkout: Un objeto en este estado ha sido traído de la base de datos de manera que puedas trabajar tu solo con él durante un período extenso. Pin: Un objeto en estado Pin, se mantendrá en la caché de objetos.
Relaciones de los objetos Embebidos: Una relación embebida sería equivalente a una "contiene-a". El objeto embebido está contenido en un objeto padre Inherente: Sirve para crear una jerarquía padre-hijo. Los hijos heredan métodos y datos de sus progenitores. Es una relación "es-un" Asociación: Con este tipo de relación se puede agrupar tipos de objetos similares. Ej: Un empleado forma parte de un departamento, esto sería una asociación de objetos del tipo empleado.
Seguridad
Tipos de Usuarios DBSA: Encargado de la instalación de Versant DBA: El usuario encargado de crear la base de datos. DB User: Usuarios que acceden a la base de datos Se puede establecer un protocolo de autenticación propio
Privilegios Acceso Público: Cualquiera puede acceder a la base de datos. No es necesaria autenticación Solo Lectura Lectura y Escritura El acceso a las diferentes herramientas de Versant ya esta predefinido. No todos los usuarios pueden acceder a todas las herramientas
Sesiones Antes de usar una base de datos, método, tipo de datos u objeto persistente se tiene que abrir una sesión. Solo se puede abrir una sesión por proceso o hilo. Al crear una sesión se crean los siguientes espacios en memoria: En memoria del cliente Object Cache: Mejora el acceso a objetos durante las transacciones Object Cache Table: Una tabla de apuntadores a todos los objetos usados en la sesión Session Tables: Almacena tus procesos, bases de datos conectadas y transacciones cortas y largas En memoria del servidor Server Page Cache: Se asocia con la base de datos de sesiones. Cada conexión guarda una página en esta caché que almacena los objetos más recientes.
Tipos de Sesiones: Standar: La sesión por defecto. Siempre se trabaja con transacciones cortas o largas y se usa el modelo estándar de bloqueo Shared: Se pueden usar múltiples procesos, ya que la memoria es compartida Multiple Threads on Multiple Sessions: Se pueden usar varios hilos en varias sesiones a la vez, cada sesión tendrá 0 o varios hilos Shared con alto rendimiento: En esta opción un proceso puede escribir mientras varios pueden leer. Optimistic Locking: Suprime el intercambio de objetos, previene las actualizaciones de cerrojos automáticas y provee de detección de colisiones.
Integridad
Transacciones Versant soporta transacciones cortas y largas en el contexto de una sesión. Las transacciones cortas son unidades lógicas de trabajo bajo el control de la aplicación. Una aplicación puede hacer explícitamente commit o roll back de una transacción corta o introducir un punto de guardado para la transacción. Cuando una sesión empieza o una transacción corta finaliza, una nueva transacción corta comienza automáticamente. Sin embargo, debes tener activados el login y el cerrojo de la base de datos. Si una transacción se trocea en más de una base de datos, se invoca automáticamente un commit en dos fases en el tiempo del commit. Las transacciones cortas cumplen con las propiedades ACID y dos más, estas son Coordinated, que hace que los objetos en una transacción estén bloqueados, y Ever-present, que te obliga a estar siempre en una transacción corta, cuando acaba una transacción corta comienza otra. Las transacciones largas comienzan y finalizan por defecto cuando la sesión comienza y finaliza. Sin embargo, puedes entrar a una transacción larga previa, esto es hacer que la transacción larga continúe en una sesión siguiente especificando el nombre y tiempo de comienzo. Se puede cambiar entre múltiples transacciones largas parando y recomenzando sesiones.
Cerrojos Hay dos tipos de cerrojos para el control de concurrencia, cerrojos cortos y cerrojos persistentes. Los cerrojos cortos se aplican sobre los objetos. Hay varios tipos de cerrojos cortos, como son de escritura, de actualización, de lectura (que pueden ser compartidos) y los llamados cerrojos nulos (usados para lecturas sucias). Se puede poner que las aplicaciones que esperan por un cerrojo acaben por tiempo. Los deadlocks en una sola base de datos son detectados y reportados inmediatamente por Versant. Usa un mecanismo de timeoup para detectar deadlocks entre múltiples bases de datos. Los cerrojos persistentes se mantienen al final de las sesiones. Tenemos varios tipos de cerrojos persistentes: de escritura, de lectura y nulos. También se puede indicar si el cerrojo se puede romper por otras aplicaciones (hard) o no (soft). Versant tiene un conjunto extenso de mecanismos de control de concurrencia y de tipos de cerrojos para activar y desactivar operaciones en el contexto de múltiples transacciones largas, mucho más extensos que los que pueda ofrecer actualmente cualquier SGBD relaccional. Esto hace posible ajustar los servicios de la base de datos evitando algunos comportamientos para ajustarse a los requerimientos de la aplicación. Sin embargo, esto es peligroso, hay que preparar bien una teoría de control de la concurrencia y unos modelos para bloquear comportamientos antes de empezar a ajustar el sistema de bloqueos de Versant.
Commit en dos fases Para asegurarse de la integridad se utiliza commits en dos fases. El commit en dos fases involucra un procedimiento en el que se comunican todas las bases para confirmar que se han guardado todos los cambios.
Optimist Locking Versant añade soporte de protocolos optimistas en casos de que se vayan a realizar pocas escrituras en la base de datos. Para poder usarlo hay que definirlo al iniciar la sesión.
Multiversion Versant almacena todas las versiones por las que haya pasado un objeto. Esto es una forma de mantener un log de todos los estados del objeto. Esto también facilita la utilización concurrente de un objeto, ya que la lectura de un objeto también crea una nueva versión. En Versant hay tres tipos de estados para las versiones de un objeto: Transitorio: Puede ser modificado y eliminado. Working: No pueden ser modificados pero si eliminados Released: No se pueden ni modificar ni eliminar. También se puede cambiar el estado de un objeto versionado, por lo que si realmente se querría borrar un estado Released habría que bajarlo antes a estado Working y luego borrarlo.
Bi-Links El tipo bi-links, mejora la integridad al poder referenciarse entre dos objetos de manera bi-direccional. Esto, además, permite más facilidades de borrado en cascada.
Recogida de Basuras Versant permite la eliminación de objetos no referenciados que no son de sistema de manera automática. Sin embargo hay que tener cuidado en tener todos los objetos referenciados o podemos perderlos. Una manera de evitar que un objeto se pueda por la recogida de basuras es definir una clase root (de sistema) y hacerlo hijo de esa clase.
Deadlocks Para evitar los bloqueos mortales Versant asigna un tiempo límite que puede estar esperando una transacción. Si ese tiempo es superado aborta la transacción y manda un aviso de posible deadlock
Recuperación
Copias de Seguridad Versant provee dos mecanismos diferentes para realizar backups. El ADB puede hacer copias de seguridad en línea o incremental. Una copia de seguridad en línea solo puede ser usada para restaurar una base de datos corrupta a un estado correcto previo, cuando se hizo el backup. Un backup incremental tiene un diario de rollforward asociado, que mantiene guardado toda la actividad de la base de datos que ocurre entre operaciones de backup. Se puede usar este diario para llegar al punto de la última transacción errónea.
Servidor de Tolerancia a Fallos Se puede usar el Servidor de Tolerancia a Fallos Versant, que es un replicador síncrono, para mantener las bases de datos libres de errores. Los contenidos de una base de datos pueden ser duplicadas a otra base de datos local o remota para formar un par de bases de datos iguales. Cuando una base de datos no puede ser accedida Versant continúa usando la restante. Cuando la base de datos estropeada vuelve a un estado operacional, Versant automáticamente resincroniza las dos bases de datos. Sin embargo, hay algunas limitaciones en la replicación síncrona. Cada base de datos solo puede tener una única réplica. Las preguntas en curso y las notificaciones de eventossolo trabajan en una única base de datos y por tanto, no se transfieren a la base de datos que está en espera. No se pueden crear ni deshacer puntos de guardado o usar transacciones anidadas cuando se usa la replicación síncrona. Los cambios de esquema tienen que ser realizados cuando ambas bases de datos estén disponibles. Sin embargo, a pesar de estas limitaciones, la replicación síncrona es un mecanismo excelente para mantener una base de datos correcta. Alternativamente se puede implementar replicación asíncrona usando los mecanismos de notificación de eventos de Versant
Optimización
Índices