Access Database Engine (también Office Access Connectivity Engine o ACE y anteriormente Microsoft Jet Database Engine , Microsoft JET Engine o simplemente Jet ) es un motor de base de datos sobre el que se han construido varios productos de Microsoft . La primera versión de Jet se desarrolló en 1992 y constaba de tres módulos que podían utilizarse para manipular una base de datos.
JET significa tecnología de motor conjunto . Microsoft Access y Visual Basic usan o han usado Jet como motor de base de datos subyacente. Sin embargo, ha sido reemplazado para uso general, primero por Microsoft Desktop Engine (MSDE) y luego por SQL Server Express . Para necesidades de bases de datos más grandes, las bases de datos Jet se pueden actualizar (o, en el lenguaje de Microsoft, "aumentar su tamaño") al producto estrella de base de datos SQL Server de Microsoft.
Una base de datos MS Jet (Red) de cinco mil millones de registros con compresión y cifrado activados requiere aproximadamente un terabyte de espacio de almacenamiento en disco [ cita necesaria ] . Normalmente consta de cientos de archivos *.mdb.
Jet, al ser parte de un sistema de gestión de bases de datos relacionales (RDBMS), permite la manipulación de bases de datos relacionales . Ofrece una interfaz única que otro software puede usar para acceder a las bases de datos de Microsoft y brinda soporte para seguridad, integridad referencial , procesamiento de transacciones , indexación , bloqueo de registros y páginas y replicación de datos. En versiones posteriores, el motor se ha ampliado para ejecutar consultas SQL , almacenar datos de caracteres en formato Unicode , crear vistas de bases de datos y permitir la replicación bidireccional con Microsoft SQL Server.
Hay tres módulos para Jet: Uno es el controlador Native Jet ISAM , una biblioteca de vínculos dinámicos (DLL) que puede manipular directamente archivos de bases de datos (MDB) de Microsoft Access utilizando una API de sistema de archivos (acceso aleatorio). Otro de los módulos contiene los ISAM Drivers , DLL que permiten acceder a una variedad de bases de datos ISAM del Método de Acceso Secuencial Indexado , entre ellas xBase , Paradox , Btrieve y FoxPro , dependiendo de la versión de Jet. El último módulo es la DLL de objetos de acceso a datos (DAO). DAO proporciona una API que permite a los programadores acceder a las bases de datos JET utilizando cualquier lenguaje de programación.
Jet permite que varios usuarios accedan a la base de datos simultáneamente. Para evitar que los datos se corrompan o invaliden cuando varios usuarios intentan editar el mismo registro o página de la base de datos, Jet emplea una política de bloqueo. Cualquier usuario puede modificar sólo aquellos registros de la base de datos (es decir, elementos de la base de datos) a los que el usuario ha aplicado un bloqueo , lo que otorga acceso exclusivo al registro hasta que se libere el bloqueo. En las versiones de Jet anteriores a la versión 4, se utiliza un modelo de bloqueo de páginas y en Jet 4, se emplea un modelo de bloqueo de registros. Las bases de datos de Microsoft están organizadas en "páginas" de datos, que son estructuras de datos de longitud fija (2 kB antes de Jet 4, 4 kB en Jet 4). Los datos se almacenan en "registros" de longitud variable que pueden ocupar menos o más de una página. El modelo de bloqueo de páginas funciona bloqueando las páginas, en lugar de registros individuales, lo que, aunque consume menos recursos, también significa que cuando un usuario bloquea un registro, todos los demás registros de la misma página se bloquean colateralmente. Como resultado, ningún otro usuario puede acceder a los registros bloqueados colateralmente, aunque ningún usuario acceda a ellos y no sea necesario bloquearlos. En Jet 4, el modelo de bloqueo de registros elimina los bloqueos colaterales, de modo que todos los registros que no estén en uso estén disponibles.
Hay dos mecanismos que Microsoft utiliza para el bloqueo : bloqueo pesimista y bloqueo optimista . Con el bloqueo pesimista, el registro o la página se bloquea inmediatamente cuando se solicita el bloqueo, mientras que con el bloqueo optimista, el bloqueo se retrasa hasta que se guarda el registro editado. Es menos probable que se produzcan conflictos con el bloqueo optimista, ya que el registro se bloquea sólo durante un corto período de tiempo. Sin embargo, con el bloqueo optimista no se puede estar seguro de que la actualización se realizará correctamente porque otro usuario podría bloquear el registro primero. Con el bloqueo pesimista, se garantiza que la actualización se realizará correctamente una vez que se obtenga el bloqueo. Otros usuarios deben esperar hasta que se libere el bloqueo para poder realizar sus cambios. Los conflictos de bloqueo, que requieren que el usuario espere o hacen que la solicitud falle (generalmente después de un tiempo de espera), son más comunes con el bloqueo pesimista.
Jet admite el procesamiento de transacciones para sistemas de bases de datos que tienen esta capacidad ( los sistemas ODBC tienen procesamiento de transacciones de un nivel, mientras que varios sistemas ISAM como Paradox no admiten el procesamiento de transacciones). Una transacción es una serie de operaciones realizadas en una base de datos que deben realizarse juntas; esto se conoce como atomicidad y es uno de los conceptos ACID (Atomicidad, Consistencia, Aislamiento y Durabilidad), considerados como las características clave del procesamiento de transacciones de una base de datos. sistema de administración de base de datos . Para que el procesamiento de transacciones funcionara (hasta Jet 3.0), el programador necesitaba comenzar la transacción manualmente, realizar las operaciones necesarias en la transacción y luego confirmar (guardar) la transacción. Hasta que se confirma la transacción, los cambios se realizan sólo en la memoria y no se escriben en el disco. [1] Las transacciones tienen una serie de ventajas sobre las actualizaciones de bases de datos independientes. Una de las principales ventajas es que las transacciones se pueden abandonar si ocurre un problema durante la transacción. Esto se denomina revertir la transacción, o simplemente revertir, y restaura el estado de los registros de la base de datos exactamente al estado anterior a que comenzara la transacción. Las transacciones también permiten que el estado de la base de datos permanezca consistente si ocurre una falla del sistema en medio de una secuencia de actualizaciones que deben ser atómicas. No hay posibilidad de que sólo algunas de las actualizaciones terminen escritas en la base de datos; O todo tendrá éxito o los cambios se descartarán cuando se reinicie el sistema de base de datos. Con la política en memoria de ODBC, las transacciones también permiten que muchas actualizaciones de un registro ocurran completamente dentro de la memoria, con sólo una costosa escritura en disco al final.
Las transacciones implícitas fueron admitidas en Jet 3.0. Estas son transacciones que se inician automáticamente después de que se confirmó la última transacción en la base de datos. Las transacciones implícitas en Jet ocurrieron cuando se emitió una declaración SQL DML . Sin embargo, se descubrió que esto tenía un impacto negativo en el rendimiento en Windows de 32 bits (Windows 95, Windows 98), por lo que en Jet 3.5 Microsoft eliminó las transacciones implícitas cuando se realizaban declaraciones SQL DML.
Jet impone la integridad de la entidad y la integridad referencial . Jet evitará de forma predeterminada cualquier cambio en un registro que rompa la integridad referencial, pero las bases de datos Jet pueden usar restricciones de propagación (actualizaciones y eliminaciones en cascada) para mantener la integridad referencial.
Jet también admite "reglas comerciales" (también conocidas como "restricciones"), o reglas que se aplican a cualquier columna para imponer qué datos se pueden colocar en la tabla o columna . Por ejemplo, se podría aplicar una regla que no permita ingresar una fecha en una columna date_logged anterior a la fecha y hora actuales, o se podría aplicar una regla que obligue a las personas a ingresar un valor positivo en un campo solo numérico. .
El acceso a las bases de datos de Jet se realiza a nivel de usuario. La información del usuario se mantiene en una base de datos del sistema separada y el acceso se controla en cada objeto del sistema (por ejemplo, por tabla o por consulta). En Jet 4, Microsoft implementó una funcionalidad que permite a los administradores de bases de datos configurar la seguridad mediante los comandos SQL CREATE, ADD, ALTER, DROP USER y DROP GROUP. Estos comandos son un subconjunto del estándar ANSI SQL 92 y también se aplican a los comandos GRANT/REVOKE. [1] Cuando se lanzó Jet 2, la seguridad también se podía configurar mediante programación a través de DAO .
Las consultas son los mecanismos que utiliza Jet para recuperar datos de la base de datos. Se pueden definir en Microsoft QBE (Consulta por ejemplo), a través de la ventana SQL de Microsoft Access o mediante el lenguaje de objetos de acceso a datos (DAO) de Access Basic. Luego se convierten en una declaración SQL SELECT . Luego se compila la consulta; esto implica analizar la consulta (implica verificar la sintaxis y determinar las columnas a consultar en la tabla de la base de datos), luego convertirla a un formato de objeto de consulta interno de Jet, que luego se tokeniza y se organiza en una estructura similar a un árbol. A partir de Jet 3.0, estos se optimizan utilizando la tecnología de optimización de consultas Microsoft Rushmore. Luego se ejecuta la consulta y los resultados se devuelven a la aplicación o al usuario que solicitó los datos.
Jet pasa los datos recuperados para la consulta en un dynaset . Este es un conjunto de datos que está vinculado dinámicamente a la base de datos. En lugar de tener el resultado de la consulta almacenado en una tabla temporal, donde el usuario no puede actualizar los datos directamente, dynaset le permite ver y actualizar los datos contenidos en dynaset. Así, si un profesor universitario consulta a todos los estudiantes que recibieron una distinción en su tarea y encuentra un error en el registro de ese estudiante, el usuario solo necesitaría actualizar los datos en el dynaset, lo que actualizaría automáticamente el registro de la base de datos del estudiante sin necesidad de permite al usuario enviar una consulta de actualización específica después de almacenar los resultados de la consulta en una tabla temporal.
Jet comenzó originalmente en 1992 como una tecnología subyacente de acceso a datos que surgió de un proyecto de desarrollo de productos de bases de datos internas de Microsoft, cuyo nombre en código era Cirrus. Cirrus se desarrolló a partir de una versión preliminar del código de Visual Basic y se utilizó como motor de base de datos de Microsoft Access . Tony Goodhew, que trabajaba para Microsoft en ese momento, dice
"Sería razonablemente exacto decir que hasta esa etapa Jet era más el nombre del equipo asignado para trabajar en los módulos del motor DB de Access que un equipo de componentes. Para VB [Visual Basic] 3.0 básicamente tenían que Sáquelo de Access e injertelo en VB. Por eso han tenido todos esos problemas con Jet/ODBC en VB 3.0."
Jet se volvió más componenteizado cuando se lanzó Access 2.0 porque los desarrolladores de Access ODBC utilizaron partes del código Jet para producir el controlador ODBC. Se proporcionó una actualización que permitió a los usuarios de Visual Basic 3.0 utilizar el Jet actualizado emitido en Access 2.0. [4]
Jet 2.0 se lanzó como varias bibliotecas dinámicas vinculadas (DLL) que eran utilizadas por el software de aplicación , como la base de datos Access de Microsoft. Las DLL en Windows son "bibliotecas" de código común que puede usar más de una aplicación; al mantener el código que usa más de una aplicación en una biblioteca común que cada una de estas aplicaciones puede usar de forma independiente, se reduce el mantenimiento del código y se reduce la funcionalidad de las aplicaciones. aumenta, con menor esfuerzo de desarrollo. Jet 2.0 constaba de tres DLL: Jet DLL, DLL de objetos de acceso a datos (DAO) y varios DLL ISAM externos. Jet DLL determinó a qué tipo de base de datos estaba accediendo y cómo realizar lo que se le solicitaba. Si la fuente de datos fuera un archivo MDB (un formato de Microsoft Access), entonces leería y escribiría los datos directamente en el archivo. Si la fuente de datos fuera externa, recurriría al controlador ODBC correcto para realizar su solicitud. DAO DLL era un componente que los programadores podían usar para interactuar con el motor Jet y era utilizado principalmente por programadores de Visual Basic y Access Basic. Las DLL de ISAM eran un conjunto de módulos que permitían a Jet acceder a tres bases de datos basadas en ISAM: xBase, Paradox y Btrieve. [2] Jet 2.0 fue reemplazado por Jet 2.1, que usaba la misma estructura de base de datos pero diferentes estrategias de bloqueo, lo que lo hacía incompatible con Jet 2.0.
Jet 3.0 incluyó muchas mejoras, incluida una nueva estructura de índice que redujo el tamaño de almacenamiento y el tiempo necesario para crear índices altamente duplicados, la eliminación de bloqueos de lectura en las páginas de índice, un nuevo mecanismo para la reutilización de páginas, un nuevo método de compactación para cuya compactación de la base de datos dio como resultado que los índices se almacenaran en un formato de índice agrupado, un nuevo mecanismo de asignación de páginas para mejorar las capacidades de lectura anticipada de Jet, operaciones de eliminación mejoradas que aceleraron el procesamiento, subprocesos múltiples (se usaron tres subprocesos para realizar la lectura anticipada , escritura retrasada y mantenimiento de caché), transacciones implícitas (los usuarios no tenían que indicarle al motor que iniciara manualmente y confirmara las transacciones en la base de datos), un nuevo motor de clasificación, valores largos (como notas o tipos de datos binarios) se almacenaban en tablas separadas y almacenamiento en búfer dinámico (donde el caché de Jet se asignaba dinámicamente al inicio y no tenía límite y que cambiaba de una política de reemplazo de búfer primero en entrar, primero en salir (FIFO) a una política de reemplazo de búfer usada menos recientemente (LRU)). [5] Jet 3.0 también permitía la replicación de bases de datos. Jet 3.0 fue reemplazado por Jet 3.5, que utiliza la misma estructura de base de datos, pero diferentes estrategias de bloqueo, lo que lo hace incompatible con Jet 3.0.
Jet 4.0 obtuvo numerosas funciones y mejoras adicionales. [1]
Las versiones de Microsoft Access desde Access 2000 hasta Access 2010 incluían un "Asistente de actualización" que podía " convertir " (actualizar) una base de datos Jet a "una base de datos equivalente en SQL Server con la misma estructura de tabla, datos y muchos otros atributos de la base de datos original". ". Esta herramienta no manejaba informes, consultas, macros ni seguridad, lo que significa que podrían haber sido necesarias algunas modificaciones manuales si la aplicación dependiera en gran medida de estas funciones de Jet. [6]
Una versión independiente del motor de base de datos Jet 4 era un componente de Microsoft Data Access Components (MDAC) y se incluía en todas las versiones de Windows desde Windows 2000 en adelante. [7] El motor de base de datos Jet era sólo de 32 bits y no se ejecutaba de forma nativa en versiones de 64 bits de Windows. Esto significaba que las aplicaciones nativas de 64 bits (como las versiones de 64 bits de SQL Server) no podían acceder a los datos almacenados en archivos MDB a través de ODBC, OLE DB o cualquier otro medio, excepto a través del software intermedio de 32 bits (que se ejecuta en WoW64) . ) que actuaba como proxy para el cliente de 64 bits. [8]
A partir de la versión 2007, Access incluye una versión de Jet específica para Office, inicialmente llamada Office Access Connectivity Engine (ACE), pero que ahora se llama Access Database Engine (sin embargo, los consultores de MS-Access y los desarrolladores de VBA que se especializan en MS-Access es más probable que se refieran a él como "el motor de base de datos ACE"). [ cita necesaria ] Este motor era compatible con versiones anteriores del motor Jet, por lo que podía leer y escribir archivos (.mdb) de versiones anteriores de Access. Introdujo un nuevo formato de archivo predeterminado, (.accdb), que trajo varias mejoras a Access, incluidos tipos de datos complejos como campos de valores múltiples, el tipo de datos adjuntos y el seguimiento del historial en los campos de notas. También trajo cambios de seguridad y mejoras de cifrado y permitió la integración con Microsoft Windows SharePoint Services 3.0 y Microsoft Office Outlook 2007. [9] [10] [11] Se puede obtener por separado. [12]
El motor de Microsoft Access 2010 dejó de admitir archivos Access 1.0, Access 2.0, Lotus 1-2-3 y Paradox. [13] Se introdujo una versión de 64 bits de Access 2010 y su controlador/proveedor ACE, que en esencia proporciona una versión de 64 bits de Jet. El controlador no forma parte del sistema operativo Windows, pero está disponible como redistribuible. [14] [15]
El motor de Microsoft Access 2013 dejó de admitir archivos de Access 95, Access 97 y xBase, y también suspendió el soporte para la replicación. [dieciséis]
La versión 1608 de Microsoft Access 2016 restauró la compatibilidad con archivos xBase, [17] y la versión 1703 introdujo un tipo de datos de número grande. [18]
Desde el punto de vista de la tecnología de acceso a datos, Microsoft considera Jet como una tecnología obsoleta, [19] pero Microsoft continúa brindando soporte a ACE como parte de Microsoft Access.
Microsoft proporciona los controladores JET únicamente para Microsoft Windows y el soporte de software de terceros para bases de datos JET se encuentra casi exclusivamente en Windows. Sin embargo, existen proyectos de código abierto que permiten trabajar con bases de datos JET en otras plataformas, incluido Linux . En particular, MDB Tools y su puerto Java muy extendido llamado Jackcess, así como UCanAccess.
{{cite web}}: CS1 maint: numeric names: authors list (link){{cite web}}: CS1 maint: numeric names: authors list (link){{cite web}}: CS1 maint: numeric names: authors list (link)