1. APACHE
DERBY.
Integrantes:
1.- Alexander Chirinos.
2.- Gaudis Castellano.

2. 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.

3. 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.

4. 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.

5. 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.

6. 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

7. CRITERIOS FUNCIONALES.
SEGURIDAD.
 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.
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

8. CRITERIOS FUNCIONALES.
 Autenticación y Métodos
SEGURIDAD.
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.

9. 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.

10. CRITERIOS FUNCIONALES.
SEGURIDAD.
Otro mecanismo de seguridad Derby, es el cifrado de disco, protege los
datos cuando el destinatario no puede saber cómo proteger los datos. Es
útil para implementar bases de datos en un entorno
integrado. Normalmente, los sistemas de bases de datos cifrar y descifrar
datos en el transporte por la red, utilizando sistemas estándar del sector.
Este sistema funciona bien para bases de datos cliente / servidor, el
servidor se supone que en un entorno de confianza y segura, gestionada
por un administrador del sistema. Además, el destinatario de los datos es
de confianza y deben ser capaces de proteger los datos. El único riesgo
viene cuando el transporte de datos a través del cable, y cifrado de datos
ocurre durante el transporte de la red solamente.
Esta función de cifrado de datos proporciona la capacidad de almacenar
datos de los usuarios de forma encriptada. El usuario que arranca la base
de datos debe proporcionar una contraseña de arranque.

11. 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.

12. CRITERIOS TECNICOS.
INTERFACES.

13. 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.

14. 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

15. 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.

16. 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

17. EVOLUCION/VERSIONES
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)