APACHE

DERBY.Integrantes:

1.- Alexander Chirinos.

2.- Gaudis Castellano.

APACHE DERBY

Es un sistema gestor de base de datos relacional escrito en Java que puede ser incrustado en aplicaciones Java y utilizado para procesos de transacciones online.

Apache Derby es un proyecto Open Source licenciado bajo la Apache 2.0 License.

Actualmente se distribuye como Sun Java DB.

HISTORIA.

Apache Derby tiene su origen en la empresa Cloudscape Inc., en Oakland, California que se fundó en 1996 para desarrollar una tecnología de base de datos para Java.

La primera versión del motor de base de datos, que por entonces se llamó JBMS, tuvo lugar en 1997.

En agosto de 2004 IBM cedió el código a la Apache Software Foundation para Derby, un proyecto patrocinado por el proyecto Apache DB. En julio de 2005 el proyecto Derby continuó desarrollándose como subproyecto base de datos de alto nivel en Apache. Sun se unió al proyecto Derby con el objetivo de utilizar como componente en sus propios productos, y con el lanzamiento de Java 6 en diciembre de 2006, Sun comenzó a empaquetar Derby en el JDK llamado Java DB.

En marzo de 2007 IBM anunció que podría comenzar a hacer marketing y dar soporte para el producto Cloudscape, pero que continuaría contribuyendo con el proyecto Apache Derby.

CRITICAS.

LA FALTA DE ESTANDARES EN LA INDUSTRIA

ORIENTADA A OBJETO.

ESTA ESCRITO EN JAVA Y NO TIENE

*BIDINGS PARA OTROS LENGUAJES.

*BIDINGS: ES UNA ADAPTACION DE UNA

BIBLIOTECA PARA SER USADA EN LENGUAJE

DE PROGRAMACION DISTINTO DE AQUEL EN

EL QUE HA SIDO ESCRITO.

CARACTERISTICAS API’s para JDBC y SQL. Soporta todas las características

de SQL92 y la mayoría de SQL99. La sintaxis SQL usada proviene de IBM DB2.

Su código pesa alrededor de 2000KB comprimido.

Soporta cifrado completo, roles y permisos. Además posee SQL SCHEMAS para separar la información en un única base de datos y control completo de usuarios.

Soporta internamente trámites, cifrado y compresión.

Trae soporte multilenguaje y localizaciones específicas.

A partir de la versión 10.4 trae un sistema simple de replicación maestro-esclavo.

Transacciones y recuperación ante errores ACID.

Posee tres productos asociados a la marca:

Derby Embedded Database Engine: El motor propiamente dicho.

Derby Network Server: Permite convertir Derby en una base de datos que sigue el modelo cliente-servidor tradicional.

Database Utilities: Un paquete de utilidades.

CRITERIOS FUNCIONALES.

INTEGRIDAD DE LOS DATOS ORGANIZACIÓN DE ARCHIVOS

En Apache Derby la organización de archivos es de tipo INDEXADA SECUENCIAL, debido a que implementa índices secundarios de SQL como Árbol B, además implementa el algoritmo estándar de Árbol B+ , ya que los nodos de la hoja, Los nodos internos sólo contienen claves y punteros. Todas las hojas se encuentran en el mismo, más bajo nivel. Los nodos hoja se encuentran unidos entre sí como una lista enlazada para permitir búsqueda secuencial. Apache Derby está constituida por los árboles B+, ya que conservan la propiedad de acceso aleatorio rápido y permiten además un recorrido secuencial rápido. En un árbol B+ todas las claves se encuentran en hojas, duplicándose en la raíz y nodos interiores aquellas que resulten necesarias para definir los caminos de búsqueda. A continuación se muestra la estructura del Árbol B+:

Bibliografía:

http://db.apache.org

Derby proporciona características de seguridad para el despliegue de bases de datos a sitios remotos

o móviles, incluyendo la autenticación utilizando una variedad de esquemas, la autorización del

usuario, soporte para ejecutar con un Administrador de seguridad de Java 2, y el cifrado de base de

datos.

CRITERIOS FUNCIONALES.

SEGURIDAD.

Acción Usuarios readOnlyAccess Usuarios FullAccess

Ejecución de sentencias SELECT X X

Leer las propiedades de base de datos X X

Carga de clases base de datos de archivos jar X X

La ejecución de INSERT, UPDATE o DELETE X

Ejecución de sentencias DDL X

Añadir o sustituir los archivos jar X

Configuración de las propiedades de base de datos X

Autenticación y Métodos

Derby proporciona soporte para la autenticación de usuario, esto significa que Derby se autentica en un nombre y una contraseña antes de permitir que el acceso del usuario al sistema. Una vez Derby autentica al usuario, que otorga al usuario el acceso al sistema de Derby, pero no necesariamente el acceso a la base de datos hecha en la solicitud de conexión. En el sistema de Derby, el acceso a una base de datos está determinada por la autorización del usuario.

Derby es compatible con una simple función a modo de mantener una lista interna de los usuarios autorizados. También es compatible con la integración de sistemas externos de autenticación de usuario, por ejemplo, se puede configurar para comprobar con un servicio de autenticación externo. Lightweight Directory Access Protocol (LDAP) se presta apoyo, y los planes personalizados son compatibles con los definidos por el usuario de Java Naming and Directory Interface (JNDI) clases.

Al no tener los nombres de usuario y contraseñas mantiene en la base de datos de medios administrativos generales menos para la transferencia de nombres en la base de datos. Esto es especialmente importante en aplicaciones de servidor desplegado.

CRITERIOS FUNCIONALES.

SEGURIDAD.

CRITERIOS FUNCIONALES.

SEGURIDAD. Reglas de Acceso para los Usuarios sobre los Objetos

Consiste en especificar los tipos de acceso que el usuario puede tener sobre los objetos de datos, tales como:

SELECT: permite que los usuarios realizar consultas de una tabla.

INSERT: permite que los usuarios agreguen datos nuevos a una tabla.

DELETE: permite que los usuarios quiten datos de una tabla.

UPDATE: permite que los usuarios actualizar datos de una tabla.

CRITERIOS FUNCIONALES.

SEGURIDAD.Otro mecanismo de seguridad Derby, es el cifrado de disco, protege losdatos cuando el destinatario no puede saber cómo proteger los datos. Esútil para implementar bases de datos en un entornointegrado. Normalmente, los sistemas de bases de datos cifrar y descifrardatos en el transporte por la red, utilizando sistemas estándar del sector.Este sistema funciona bien para bases de datos cliente / servidor, elservidor se supone que en un entorno de confianza y segura, gestionadapor un administrador del sistema. Además, el destinatario de los datos esde confianza y deben ser capaces de proteger los datos. El único riesgoviene cuando el transporte de datos a través del cable, y cifrado de datosocurre durante el transporte de la red solamente.

Esta función de cifrado de datos proporciona la capacidad de almacenardatos de los usuarios de forma encriptada. El usuario que arranca la basede datos debe proporcionar una contraseña de arranque.

CRITERIOS TECNICOS.

INTERFACES.

ARQUITECTURA DEL MOTOR DERBY

El sistema se compone de un monitor y una colección de módulos.

Monitor

Es el controlador JDBC que se asigna para la aplicación del Derby de acuerdo a la petición en la solicitud y el medio ambiente.

Esto permite a Derby de presentar un único controlador JDBC para la aplicación, independientemente de JDK e internamente el controlador correcto se carga.

CRITERIOS TECNICOS.

INTERFACES.

CRITERIOS TECNICOS. Manejo

de Datos.

Apache Derby implementa

el mecanismo llamado

Aqua Data Studio, el cual

es una herramienta de

consulta de datos, que

permite crear, editar y

ejecutar de forma rápida

consultas y scripts SQL.

CRITERIOS TECNICOS. Manejo

de Datos.

El optimizador en Apache Derby hace búsqueda de profundidad de izquierda a derecha, es decir el primer elemento de la matriz es la tabla de la izquierda en la unión del árbol. Hasta ahora es uno de los planes que ha dado mejores resultados en cuanto a las búsquedas de consultas.

El optimizador elige el orden de combinación de tablas sólo en simples cláusulas FROM. La mayoría se une con la palabra clave JOIN se acoplan en simples combinaciones, por lo que el optimizador elige su orden de combinación y no elige el orden de combinaciones externas, sino que utiliza el orden especificado en la declaración, así mismo compara el costo de elegir una combinación hash, y elige la estrategia más barata.

Bibliografía:- http://db.apache.org

CRITERIOS TECNICOS. Manejo

de Datos.DICCIONARIO / DIRECTORIO DE DATOS (D/D)

Un diccionario de Datos contiene las características lógicas de los

datos que se van a utilizar en el sistema que estamos

programando. Es decir, almacenan la información sobre los datos

relacionado con el origen, descripción, relación con otros datos,

uso, responsabilidad y formato. En el SMBD Apache Derby, el D/D

contiene objetos como tablas, columnas índices y archivos jar.

Además, almacena en archivos que residen en un directorio del

mismo nombre que la base de datos. también suelen vivir en los

directorios del sistema, conteniendo archivos y directorios tales

como:

log directory: este directorio contiene los archivos que componen

el registro de transacciones de bases de datos, de uso interno para

la recuperación de datos

seg0 directory: contiene un archivo para cada tabla de usuario,

tabla de sistema, y el índice

tmp directory: es un directorio temporal utilizado por una variedad

de sentencias

jar directory: en este directorio se almacenan los archiv0s jar.

CRITERIOS TECNICOS.

INTEGRIDAD DE LOS DATOS.

Integridad de Dominio: La integridad de dominio viene dada por la

validez de las entradas para una columna determinada, es decir,

se encarga de proteger los datos en una columna de la base de

datos.

Integridad Referencial: La integridad referencial protege las

relaciones definidas entre las tablas cuando se crean o se eliminan

filas. La integridad referencial se basa en las relaciones entre

claves externas y claves principales.

Ejemplo:

Nombre de la base de datos: AdventureWorks

Tablas de la base de datos: SalesOrderDetail, Product

La integridad referencial se basa en la relación entre la clave

externa (ProductID) de la tabla SalesOrderDetail y la clave

principal (ProductID) de la tabla Product. Esta relación garantiza

que un pedido de ventas no pueda nunca hacer referencia a un

producto que no existe en la tabla Product. Como también se

puede observar gráficamente;

Bibliografía:

- http://db.apache.org

Versiones Oficiales.10.11.1.1 (26 de agosto 2014 / SVN 1616546)10.10.2.0 (15 de abril 2014 / SVN 1582446)

Archivado de estrenos oficiales.10.8.3.0 (16 de noviembre de 2012 / SVN 1405108)10.10.1.1 (15 de abril 2013 / SVN 1458268)10.9.1.0 (25 de junio de 2012 / SVN 1344872)10.8.2.2 (24 de octubre 2011 / SVN 1181258)10.8.1.2 (29 de abril 2011 / SVN 1095077)10.7.1.1 (14 de diciembre 2010 / SVN 1040133)10.6.2.1 (05 de octubre 2010 / SVN 999685)10.6.1.0 (19 de mayo 2010 / SVN 938214)10.5.3.0 (21 de agosto 2009 / SVN 802917)10.5.1.1 (28 de abril 2009 / SVN 764942)10.4.2.0 (5 de septiembre, 2008 / SVN 689064)10.3.3.0 (12 de mayo 2008 / SVN 652961)

10.4.1.3 (24 de abril 2008 / SVN 648739)10.2.2.0 (12 de diciembre de 2006 / SVN 485682)10.2.1.6 (02 de octubre 2006 / SVN 452058)10.1.3.1 (30 de junio 2006 / SVN 417277)10.1.2.1 (18 de noviembre 2005 / SVN 330608)10.1.1.0 (03 de agosto 2005 / SVN 208786)

EVOLUCION/VERSIONES