Articulo de referencia

ObjectDatabase++

[http://www.ekkysoftware.com/Downloads Ekky Software] {{webarchive|url=https://web.archive.org/web/20120929044431/http://www.ekkysoftware.com/Downloads |date=2012-09-29 }} "},"o...

ObjectDatabase++ ( ODBPP ) es una base de datos orientada a objetos integrable , diseñada para aplicaciones de servidor que requieren un mantenimiento externo mínimo. Está escrita en C++ como una base de datos ISAM en tiempo real con capacidad de recuperación automática ante fallos del sistema, manteniendo la integridad de la base de datos. Su exclusivo proceso de transacciones permite el mantenimiento tanto de los índices como de las tablas, evitando la doble asignación de entradas de índice que podría impedir la reversión de las transacciones.

Las características de ODBPP incluyen: control total de transacciones multiproceso y multihilo, recuperación automática de la base de datos en tiempo real , diseño jerárquico de datos de objetos, acceso a código nativo y scripts, índice hash estático en los ID de los objetos, numerosos métodos de indexación compatibles, incluyendo coincidencia de patrones biométricos y de texto completo .

Historia

  • El desarrollo inicial fue implementado por Ekky Software entre 2001 y 2003.
  • Fueron necesarias cuatro reescrituras completas de la base de datos antes de que las pruebas confirmaran que cumplía con las especificaciones y funcionaba según lo previsto.
  • En la última década, numerosas mejoras en los productos han permitido una compatibilidad mucho mayor con índices y datos.

Objetos de datos jerárquicos

Muestra el diseño tradicional de bases de datos relacionales.
Muestra el diseño de la base de datos de objetos.

ODBPP admite objetos con un diseño jerárquico, [ 3 ] [ 4 ] similar a XML , JSON o PHP serializado . Es este objeto jerárquico el que distingue a las bases de datos de objetos de sus contrapartes relacionales, y es el proceso de mantener el objeto completo en un solo registro en lugar de distribuirlo en múltiples tablas lo que les confiere a las bases de datos de objetos la diferencia del modelo relacional.

Diseño relacional tradicional

Tradicionalmente, las bases de datos se han diseñado con el modelo relacional. Este modelo separa los datos en varias tablas y utiliza un identificador común para relacionar todos los registros secundarios con su registro principal. Cada fila de la tabla contiene datos individuales. Las bases de datos SQL basadas en este diseño crean uniones que vuelven a conectar toda la relación, lo que conlleva limitaciones de rendimiento. [ 5 ]

Diseño de bases de datos de objetos

En el diseño de bases de datos orientadas a objetos, en lugar de usar varias tablas para almacenar un objeto de datos, este se almacena en un único registro. Esto mantiene el objeto completo intacto y reduce la necesidad de recombinar los datos. Este proceso de almacenar el objeto completo en una sola tabla reduce la cantidad total de operaciones de bloqueo, lectura y escritura necesarias. Además, esta capacidad de almacenar un objeto en un solo registro reduce la cantidad de lecturas y escrituras de archivos, lo que permite que el diseño orientado a objetos mantenga la eficiencia incluso con bases de datos muy grandes y complejas.

Observando las imágenes de la derecha, la superior muestra el modelo relacional, con los datos distribuidos en dos tablas: la tabla principal en color ámbar y las tablas secundarias en azul. En el modelo de objetos, tanto la tabla principal como las secundarias se almacenan en un único registro de datos; la información que antes se almacenaba en la tabla relacionada ahora se almacena en la subtabla o tabla anidada de Foo.

Control de transacciones multiproceso

ODBPP implementa un control de transacciones que permite que un proceso continúe mientras otro finaliza. Este control de transacciones único permite que el proceso en ejecución identifique la transacción finalizada, recupere la integridad de la base de datos y continúe a mitad de la transacción. Es esta capacidad de finalizar una transacción en cualquier punto lo que posibilita la implementación de transacciones en tiempo real por parte del servidor mediante este método.

El control de transacciones utiliza cuatro archivos separados para implementar todo el proceso y guarda cada cambio de estado en la unidad antes de continuar al siguiente estado. Esto crea un proceso lento donde cada escritura individual en un archivo tiene tres estados distintos y toda la transacción debe pasar por tres archivos separados. Inicialmente, todas las adiciones, ediciones y eliminaciones se escriben en un archivo de memoria compartida, lo que permite que todas las transacciones sepan si se ha asignado un recurso, como un valor de índice. Este archivo de memoria se puede destruir cuando se inicia el sistema operativo sin interferir con la integridad de la base de datos y solo se utiliza para fines de comunicación entre procesos (IPC) .

Una vez que una transacción llama al método de transacción de confirmación, la base de datos realiza la mayor parte del trabajo y escribe la transacción completa desde el archivo de memoria al archivo de registro. Esto se realiza mediante un proceso de tres etapas: primero, se identifican los cambios necesarios; luego, se vacían esos planes al final del archivo; una vez escritos en la unidad, se actualiza el encabezado para indicar la presencia de la actualización; en segundo lugar, se actualiza el archivo; y finalmente, se modifica el encabezado para finalizar la actualización. Este proceso de estado garantiza la consistencia del archivo, ya que si el proceso se detiene durante la primera etapa, el archivo simplemente se trunca y se devuelve a su estado original; y si la transacción se detiene durante la segunda etapa, la siguiente transacción abre el archivo, identifica los planes guardados y vuelve a ejecutar esas instrucciones guardadas.

Cada uno de los cuatro archivos se actualiza de esta manera. La transacción comienza en el archivo de memoria, antes de ser escrita en una actualización al archivo de registro. Una vez que la transacción está protegida y asegurada en el archivo de registro, el ODBMS puede actualizar los archivos de índice y tabla. Todo el proceso de confirmación se puede ejecutar concurrentemente con múltiples transacciones confirmándose simultáneamente y se beneficia enormemente del uso de una unidad de estado sólido , aunque el proceso de almacenar en caché toda la transacción en el archivo de memoria y confirmarla en la unidad solo al final ayuda a reducir el tiempo total de la transacción y es comparable a los DBMS sin vaciado .

Índices compatibles

A diferencia de algunos de los modelos de bases de datos de objetos anteriores, [ 6 ] [ 7 ] como base de datos de nivel ISAM , ODBPP admite una gran variedad de índices. Durante el desarrollo inicial del modelo de objetos, el diseño básico consistía en utilizar un esquema que contenía únicamente un objeto binario serializado al que se hacía referencia por su ID y que no proporcionaba ningún otro acceso al índice. Esto impedía la búsqueda básica por etiquetas, etc., y se debía a que la arquitectura subyacente aún se basaba en el modelo relacionado. Dado que ODBPP siempre se diseñó con el modelo de objetos, comprende la naturaleza jerárquica de los objetos y es capaz de indexar los datos que contienen.

Índice hash estático

Todos los objetos de la base de datos se referencian mediante su identificador, que a su vez se gestiona mediante un índice hash estático . Un índice hash estático es simplemente un índice de matriz donde la ubicación que contiene la dirección del objeto se deduce multiplicando el valor del ID por 12 y sumándole un valor de desplazamiento. Esto revela la ubicación de la dirección física del objeto. Este método, que traduce el ID a su dirección física, permite una recuperación de datos de orden uno ( O (1)), independientemente de la cantidad de objetos almacenados en la base de datos.

Imponer el índice estático en todos los esquemas de tabla permite la compactación en tiempo real del archivo, ya que los bloqueos de objetos se aplican al índice y no al objeto en sí. Esto permite que incluso los objetos bloqueados se muevan dentro del archivo mediante otras transacciones que requieren más espacio o que eliminan objetos del archivo. Esta capacidad de mover objetos dentro del archivo en cualquier momento también impone la necesidad de acceder a ellos a través del índice, [ 8 ] mientras que las bases de datos SQL pueden escanear todos los registros recorriendo el archivo de principio a fin, la compactación en tiempo real prohíbe este estilo de acceso.

Índices de árbol B+

El índice de árbol B+ es la herramienta principal de todas las bases de datos, y ODBPP no es una excepción. La mayoría de las búsquedas se realizan accediendo a una posición del índice y luego buscando repetidamente el siguiente valor más grande. ODBPP admite una gran cantidad de filtros en el árbol B+ para que los resultados sean más útiles. Por ejemplo, se puede configurar para convertir todos los caracteres en minúscula a mayúscula, o para eliminar espacios en blanco o caracteres no alfanuméricos, y también para proporcionar un orden de clasificación natural donde el '9' aparece antes que el '10'.

Una de las ventajas de ODBPP sobre los sistemas de gestión de bases de datos estándar es que los datos almacenados en objetos jerárquicos también pueden indexarse. Esto crea una situación en la que se generan entre 0 y n valores de índice para cada objeto.

Índices espaciales y temporales

Los índices espaciales se utilizan para permitir búsquedas en espacios de coordenadas bidimensionales y tridimensionales. Los índices temporales se basan en una idea similar, pero en una dimensión temporal.

Coincidencia de patrones biométricos

ODBPP también admite conjuntos de datos espaciales que representan puntos clave de objetos bidimensionales y tridimensionales, como huellas dactilares o rostros humanos. Estos conjuntos se indexan mediante un índice espacial que permite realizar búsquedas grupales. La búsqueda crea un índice temporal con tantos objetos como puntos coincidan con el patrón de búsqueda o superen un margen de error determinado.

Búsqueda de texto completo

ODBPP proporciona indexación de texto completo a través de los índices de la lista de tokens. Estos índices son una combinación del árbol B+ y un desbordamiento de cubeta, donde una cadena de texto se divide en sus tokens individuales y se indexa en un árbol B+ y, dado que varios objetos tendrán el mismo valor de token, el ID se almacena en un desbordamiento de cubeta (similar al hash dinámico ). Con este diseño, las búsquedas de texto completo se realizan escaneando todos los tokens en las hojas del árbol B+ e identificando qué tokens se ajustan a los criterios de búsqueda y recuperando los ID coincidentes.

La consulta de búsqueda de texto completo también proporciona funciones lógicas para reducir los resultados a un número manejable. Por ejemplo, permite al usuario buscar objetos que contengan el token A pero no el token B.

Ejemplo de implementación

Conceptos básicos de la interfaz

ODBPP ha sido diseñado para funcionar tanto en un estilo procedimental como en un estilo de objetos encapsulados de C++ . Si bien el estilo de objetos sigue utilizando el método procedimental para interactuar con la base de datos a bajo nivel, en el ejemplo se muestra el método procedimental.

Ejemplo nativo

clase Foo { public : enum { TableID = 1 }; unsigned int ParentID ; // id para vincular con el padre de este objeto unsigned int Flags [ 4 ]; // 0x01 – tiene padre enum { Name , //la etiqueta dada al objeto Foo Description //una descripción de Foo }; } * fooObject ; base de datos CODBPP ; CODBPP :: Object object ; unsigned int error ; char16_t * fooName = TEXT ( "FooName" ), * message , buffer [ 128 ]; if (( error = database . OpenDatabase ( TEXT ( "C: \\ Ruta \\ a \\ Database.odc" ))) == NO_ERROR && ( error = database . BeginTransaction ()) == NO_ERROR && ( error = database . OpenTable ( Foo :: TableID )) == NO_ERROR && ( error = database . ReadObject ( Foo :: TableID , CODBPP :: EQUALTO , & object , 1 , fooName )) == NO_ERROR ){ fooObject = ( Foo * ) object . fixed ; swprintf_s ( buffer , __countof ( buffer ), TEXT ( "Padre = %d, Indicadores = %d" ), fixedObject -> ParentID , fooObject -> Flags [ 0 ]); MessageBox ( buffer ); } if ( error&& base de datos . ObtenerMensajeDeError ( & mensaje ) == NO_ERROR ) MessageBox ( mensaje ); base de datos . FinTransacción ();

Ejemplo de TScript

El ejemplo equivalente en TScript para leer un objeto de la base de datos que tiene el nombre "FooName" es el siguiente.

#incluir "ODBPP.ts"public main ( variable parameters = null : Structure results ) { ODBPP database ; ODBPP . Object objectHandle ; database . OpenDatabase ( L "c: \\ Ruta \\ a \\ Database.odc" ); database . BeginTransaction (); database . OpenTable ( 1 ); database . ReadIndex ( 1 , CODBPP . EQUALTO , 1 , L "FooName" : objectHandle ); database . FragmentObject ( 1 , objectHandle : results ); System :: MessageBox ( L "Padre = " + results . ParentID + L ", Indicadores = " + results . Flags ); }

Ejemplo en C#

ObjectDatabase++ también se expone a través de la clase contenedora COM 'ODBPPLib.ODBPP'. El ejemplo equivalente en C# para leer un objeto de la base de datos con el nombre "FooName" es el siguiente.

private void button1_Click ( object sender , EventArgs e ) { try { ODBPPLib . ODBPP odbpp = new ODBPPLib . ODBPP (); odbpp . OpenDatabase ( @"C:\Path\To\Database.odc" ); odbpp . BeginTransaction ( odbpp . SHARED , 6000 ); odbpp . OpenTable ( 1 ); ODBPPLib . DatabaseObject results = odbpp . ReadObject ( 1 , odbpp . EQUALTO , 1 , "FooName" ); if ( results != null ) MessageBox . Show ( "Parent = " + results . readField ( "ParentID" ) + ", Flags = " + results . readField ( "Flags" )); } catch ( Exception e1 ) { MessageBox . Show ( e1 . Message ); } }

Referencias

  1. Ekky Software Archivado el 29/09/2012 en Wayback Machine
  2. "Ekky Software Sales" . Archivado del original el 21/08/2013 . Consultado el 02/08/2013 .
  3. Khoualdi, K, & Alghamdi, T 2011, 'Desarrollo de sistemas mediante bases de datos orientadas a objetos: Estudio práctico sobre el sistema ISO 9001:2000', Journal of Software Engineering & Applications, 4, 12, pp. 666–671, Computers & Applied Sciences Complete
  4. Naser, T, Alhajj, R, & Ridley, M 2009, 'Mapeo bidireccional entre bases de datos orientadas a objetos y XML', Informatica (03505596), 33, 3, pp. 297–308, Computers & Applied Sciences Complete
  5. Suri, P. y Sharma, M. 2011, «Un estudio comparativo entre el rendimiento de las bases de datos relacionales y orientadas a objetos en el almacenamiento de datos», International Journal of Database Management Systems, 3, 2, pp. 116–127, Computers & Applied Sciences Complete
  6. Hardwick, M, Samaras, G, 1989, 'Uso de una base de datos relacional como índice de una base de datos de objetos distribuidos en sistemas de diseño de ingeniería', Sistemas de datos y conocimiento para la fabricación y la ingeniería, 1989, Segunda Conferencia Internacional. Fecha de la conferencia: 16-18 de octubre de 1989.
  7. Zhang, F, Ma, Z, & Yan, L 2011, 'Construction of ontologies from object-oriented database models', Integrated Computer-Aided Engineering, 18, 4, pp. 327–347, Computers & Applied Sciences Complete
  8. Lee, KCK; Hong Va Leong; Si, A. 2003, 'Aproximación de la ubicación de objetos para bases de datos de objetos en movimiento', Talleres de Sistemas de Computación Distribuida, 2003. Actas. 23.ª Conferencia Internacional. Fecha de la conferencia: 19-22 de mayo de 2003.
  • Introducción a ObjectDatabase++