Avisar de contenido inadecuado
Expand

Conexiones de aplicaciones con Bases de Datos

La relación de los clientes con los servidores de bases de datos podría ser como en la primera figura pero lamentablemente no se ha logrado que los diferentes fabricantes lleguen a estándares respetados por todos que lo permita. Solamente las especificaciones de SQL (de vital importancia en las relaciones Cliente/Servidor) han sobrevivido medianamente. Hay que recordar que solo SQL 3 ha enfrentado tópicos de gran envergadura como módulos persistentes, relaciones avanzadas cliente/servidor y datos abstractos; y que aun los proveedores no hacen sus productos compatibles con este estándar.
Cuando un desarrollador enfrenta un proyecto enmarcado en Cliente/Servidor de Bases de Datos debe enfrentar una serie de inconvenientes que debe resolver, en particular la conexión y manipulación de la información en la base de datos a través del SGBD o DBMS.

El esquema siguiente muestra esta situación:

 

 

Como se aprecia el programador debe recurrir a APIs (Interfaz para el Programador de Aplicaciones), que son funciones que proveen los fabricantes de hardware y/o software para que los programadores no deban llegar a bajo nivel para relacionarse con sus productos y lo hagan conociendo tales funciones. Como se dijo anteriormente, dado que no hay un estándar, cada compañía ha dispuestos su APIs específicas.

Estas funciones actúan sobre los controladores o drivers (similares a los drivers para impresoras, cámaras, etc), quienes se comunican con el sistema operativo y poner a disposición sus productos. Tampoco los drivers son estándar y existe por lo menos uno para cada producto. Para que la aplicación se pueda comunicar con la Base de Datos debe tenerse habilitado este driver.

Por último, en caso de estar en red, se debe tener protocolos comunes de comunicación entre clientes y servidores o traductores de los mismos. En esto los estándares están muy avanzados y son respetados, por lo cual pocas veces hay problema con ello.
Se debe tener presente un caso más general, en el cual una aplicación tenga que comunicarse con diferentes DBMS, esto complica aun mas la situación.

Controladores o Drivers. Paul Reed, dice que el controlador es clave para desentrañar los misterios del DBMS. Los controladores reciben la llamada de las CLI y la traducen al lenguaje de acceso nativo del servidor de bases de datos. Se requiere un controlador por cada base de datos con la que se realiza conexión.

APIs de SQL. Dos métodos prevalecen para el soporte de SQL con lenguajes de programación:
SQL embebido ESQL
Interfaz del Nivel de Llamada (CLI).

SQL incrustado o embebido ha sido atendido por la especificación SQL-92, para la inclusión de instrucciones SQL (realmente no es una API) como si fuesen instrucciones propias del lenguaje de programación ordinario. Deben enmarcarse entre etiquetas que permiten ser distinguidas de las demás instrucciones. Estos bloques serán previamente precompilados. Tiene como inconvenientes que la base d datos destino debe conocerse al momento del desarrollo y que las instrucciones son diferentes para cada producto.

Las interfaces del nivel de llamada (CLI) son APIs de SQL para acceso a bases de datos, por lo cual no se requiere precompilación ni conocer de antemano la base de datos. Esto facilitaría la independencia del producto en particular, pero acá tampoco los estándares han triunfado.

CLI de SAG. SAG es un consorcio constituido en 1988 por 44 proveedores con el fin de ofrecer u estándar unificado para el acceso a bases de datos remotas. El CLI de SAG es un conjunto de API para base d datos SQL, aportando semántica y sintaxis de SQL común. Permiten conexiones a través de un controlador local, preparar solicitudes, ejecutar solicitudes, recuperar resultados, concluir instrucciones y concluir conexiones.
Varios productos en el mercado se adecuan a esta especificación.

CLI de Microsoft. Es una versión ampliada de la CLI de SAG, conocida como Conectividad de Bases de Datos Abierta (ODBC: Open DataBase Connectivity), inicialmente para acceso de bases de datos con Windows.
OBDC es una interface programada que hace posible el acceso a información en sistemas manejadores de bases de datos que usan SQL (Structured Query Language) como un estándar de acceso a datos. ODBC posee drivers que se instalan por defecto y permite también que el usuario los instale según la base de datos con la que desee obtener conexión.
Para conseguir la conexión, ODBC hace posible la configuración de un origen de datos DSN (Data Source Name), que contiene los detalles necesarios para la comunicación con la base de datos como el driver a emplear, seguridad y la localización física.
La creación de un DSN puede estar definida por aspectos que determinen que tipo de origen de datos se desea:
DSN de usuario: Almacena la información de cómo conectar al gestor de datos indicado. Este es solamente visible por el usuario y puede ser usado únicamente en la máquina actual.
DSN de sistema: Almacena información necesaria para la conexión con el gestor correspondiente. Es visible por todos los usuarios de la máquina, incluyendo los servicios NT.
DSN de archivo: Permite la conexión con el distribuidor de datos disponible y además puede ser compartido por usuarios que tengan el mismo controlador instalado.

API de Borland/Inprise. Borland Database Engine (BDE) es el motor común para acceso de datos en sus productos. IDAPI (Integrated Database API) es la API para este motor, que unifica los accesos y las consultas orientadas de datos en un modelo de cursor.
IDAPI ofrece una interfaz de red que permite que los controladores residan en una maquita "gateway", lo que facilita los accesos a servidores múltiples (por lo que requerían un controlador distinto para cada uno). Todas las combinaciones de controladores residen una máquina en lugar de en cada cliente. A pesar de ser más veloz que ODBC no logro extenderse tanto como este.

API JAVA. Estándar llamado JDBC (Java DataBase Conectivity).
JDBC es realmente un conjunto de clases que representan conexiones con bases de datos, sentencias SQL, conjuntos de datos y metadatos entre otras cosas. El API definido por JDBC permite a los programadores enviar sentencias en SQL al motor de bases de datos, y procesar los resultados.
Como en los otros casos se requiere de un driver o controlador, en este caso JDBC.
Los drivers JDBC se han clasificado en tipos. La siguiente grafica tomada de www.audisoft.com, lo ilustra:

{
}

!Sobre el blog

Este blog esta basado principalmente en ofrecer informacion a los visitantes, sobre los avanzaces mas importantes en las bases de datos actuales asi como tambien en los conceptos basicos necesario para el manejo de las mismas

Leer más sobre este blog en Obolog

Expand

Seguridad en Base de Datos

La seguridad de bases de datos es la disciplina que se encarga de proteger los datos del acceso de usuarios no autorizados. La integridad, en cambio, es la disciplina que se encarga de cuidar los datos de usuarios que están autorizados.

Las restricciones de seguridad están agrupadas en dos ramas. Por un lado están las que requiere la organización que posee la base de datos, mientras que por el otro están los aspectos legales. Este último grupo de requerimientos cobra cada vez más importancia ya que en varios países se promulgaron últimamente leyes de protección a los datos personales.

Las empresas estudian como mejorar sus medidas de seguridad organizacionales, ya que pueden tomar decisiones sobre ellas. El otro tipo de seguridad, en cambio, es de cumplimiento obligatorio.

La seguridad como actividad puede dividirse en planificación e implementación. La planificación determina qué usuario puede hacer qué cosas sobre qué datos. Como la planificación es una política, está a cargo del Administrador de Datos. La implementación, en cambio, le corresponde al Administrador de Base de Datos, quien tiene una función técnica.

Los dos grandes modelos de seguridad se conocen como control discrecional y control obligatorio. El primero divide a los usuarios en grupos que tienen determinados permisos y privilegios, mientras que el último es un sistema jerárquico en el que cada usuario tiene un nivel de clasificación. El control discrecional es el más difundido de los dos.

El Sistema de Gestión de Base de Datos, conocido como DBMS por su sigla en inglés, ocupa un rol importante en la seguridad. No sólo se encarga de almacenar todas las restricciones de seguridad en el catálogo, sino que además posee un proceso que evalúa constantemente que las reglas estén siendo cumplidas. Este proceso, que no es más que un hilo de ejecución dentro del DBMS, es conocido como el subsistema de seguridad.

Expand

Procesamiento de Transacciones en Sistemas Distribuidos

Transacción

Una transacción es una unidad lógica de trabajo, la cual no necesariamente consta de una sola operación en la base de datos; más bien, es en general una secuencia de varias de esas operaciones mediante la cual un estado consistente de la base de datos se transforma en otro estado consistente, sin conservar por fuerza la consistencia en todos los puntos intermedios. El punto importante aquí es asegurar que la base de datos regresa a un estado consistente al fin de la ejecución de una transacción. Una transacción es también la invocación a un procedimiento remoto (RPC) que ejecuta un conjunto de operaciones sobre una base de datos bajo el principio de todo o nada.

El concepto fundamental aquí es la noción de "ejecución consistente" o "procesamiento confiable" asociada con el concepto de una consulta. El concepto transacción es usado dentro del dominio de la base de datos como una unidad básica de cómputo consistente y confiable.

 

Mecanismos de recuperación

A fin de soportar una respuesta favorable para la ejecución de transacciones, el DBMS (Sistema Manejador de Bases de Datos) deberá de manejar el procesamiento de transacciones. Esto es, deberá de garantizar que si la transacción ejecuta algunas modificaciones y después se presenta una falla (por cualquier razón), antes de que llegue al termino normal de la transacción, se anularán esas modificaciones. Así, o bien se lleva a cabo la transacción en su totalidad, o se cancela en su totalidad. De esta manera puede lograrse que una secuencia de operaciones, la cual en esencia no es atómica, aparente serlo desde un punto de vista externo. El componente del sistema encargado de lograr esta apariencia de atomicidad se conoce como Manejador de transacciones, y las operaciones de COMMIT (comprometer) y ROLLBACK (retroceder) son la clave de su funcionamiento.

La operación COMMIT señala el término exitoso de la transacción: le dice al manejador de transacciones que se ha finalizado con éxito una unidad lógica de trabajo, que la base de datos esta (o debería estar) de nuevo en un estado consistente, y que se pueden hacer permanentes todas las modificaciones efectuadas por esa unidad de trabajo.

La operación ROLLBACK, en cambio, señala e término no exitoso de la transacción: le dice al manejador de transacciones que algo salió mal, que la base de datos podría estar en un estado inconsistente y que todas las modificaciones efectuadas hasta el momento por la unidad lógica de trabajo deben retroceder o anularse.

 

PROPIEDADES ACID (Atomicity, Consistency, Isolation, Durability)

Una transacción posee cuatro propiedades fundamentales

Atomicidad.

Una Transacción es una unidad de trabajo indivisible; la totalidad de sus acciones son un éxito un fracaso ("todo o nada"). Consistencia. Después de ejecuta una Transacción debe dejar al sistema en estado correcto o debe abortarlo. Si la Transacción no puede alcanzar un estado final debe regresar al sistema a su estado original. Aislamiento. El comportamiento de una Transacción no se ve afectado por el hecho de que otras Transacciones puedan estar ejecutándose de manera concurrente; dicho de otra manera, una Transacción no puede revelar sus resultados a otras Transacciones concurrentes antes de su commit. La Transacción debe serializar todos los accesos a recursos compartidos y garantizar que ningún programa concurrente interferirá con sus operaciones respectivas.

Durabilidad.

 Los efectos de una Transacción son permanentes después de su grabación. Sus cambios deben sobrevivir a fallas del sistema. (Persistencia). BITÁCORA La operación ROLLBACKesta basada en el uso de una ?bitacora?. El DBMS (Sistema Manejador de Bases de Datos) mantiene una bitácora o diario en cinta o en disco (mas comúnmente), en el cual se registran los detalles de todas las operaciones de actualización, en particular, los valores inicial y final del objeto modificado. Por tanto, si resulta necesario anular alguna modificación específica, el sistema puede utilizar la entrada correspondientede la bitácora para restaurar el valor original del objeto restaurado. PUNTO DE SINCRONIZACION Las operaciones COMMIT y ROLLBACK establecen lo que se le conoce como punto de sincronización lo cual representa el límite entre dos transacciones consecutivas, o el final de una unidad lógica de trabajo, y por tanto al punto en el cual la base de datos esta (o debería estar) en un estado de consistencia. Las únicas operaciones que establecen un punto de sincronización son COMMIT, ROLLBACK y el inicio de una programa. Cuando se establece un punto de sincronización:

Se comprometen o anulan todas las modificaciones realizadas por el programa desde el punto de sincronización anterior. Se pierde todo posible posicionamiento en la base de datos. Se liberan todos los registros bloqueados.

Es importante advertir que COMMIT y ROLLBACK terminan las transacción, no el programa.

TIPOS DE TRANSACCIONES

Transacciones simples distribuidas. Una T simple puede correr en sitios múltiples y actualizar recursos localizados dentro de administradores de recursos múltiples. Transacciones encadenadas (syncpoint, encadenadas y sagas). Un syncpoint es un punto de sincronización que permite el guardado periódico del trabajo acumulado dentro de una transacción, permitiendo de esta forma dar marcha atrás al trabajo sin, abortar la transacción. Sin embargo este trabajo no es almacenado permanentemente, por lo que si el sistema se colapsa el trabajo se pierde. Las transacciones encadenadas son una variación de los syncpoint que convierten en durable el trabajo acumulado. Las sagas extienden las transacciones encadenadas a fin de dar marcha atrás a una cadena entera si es necesario.

Transacciones anidadas. Ofrecen la posibilidad de definir transacciones dentro de otras transacciones. cada subtransacción puede emitir una grabación o retroceso para las piezas de trabajo asignadas.

Transacciones simples. Todas las operaciones se llevan acabo en el mismo nivel dentro de una T La Transacción empieza con un begin_transaction y termina ya sea con un commit_transaction o abort_transaction. Toda la transacción es indivisible. En un principio las Transacciones simples fueron suficientes por su sencillez y por su adaptación a operaciones bancarias breves. Actualmente las Transacciones han incursionado en todas las facetas de la computación pero no han resultado lo más adecuado, ya que tienen un comportamiento:

  • Frágil: En transacciones de negocios que se extienden por períodos largos.
  • Débil: En procesamiento por lotes.
  • Nulo:Situaciones que requieren dar marcha atrás

Una Transacción simple no dura más de dos o tres segundo para evitar monopolizar recursos críticos del sistema como candados sobre la base de datos. Así que los programas OLTP se dividen en transacciones breves ejecutadas una tras otra para producir resultados.

MONITORES TP (Transaction Processing) Un monitor de TP es un sistema operativo de procesamiento de transacciones que tiene como funciones principales:

Administración de procesos:

    Poner en marcha los procesos del servidor Canalizar el trabajo en dirección a ellos Vigilar su correcta ejecución Equilibrar cargas de trabajo

Administrador de transacciones

    Garantiza las propiedades ACID para todo los programas bajo su protección.

 

Los monitores se especializan en la administración de transacciones desde su punto de origen (por lo general en el cliente), ya través de uno o más servidores, para luego volver al cliente originario. Cuando una T llega a su fin, el monitor de TP debe cerciorarse de que todos los sistemas involucrados en ella queden en estado consistente. De esta forma un monitor de TP sabe como correr T, enrutarlas entre diferentes sistemas, equilibrar las cargas de ejecución y ponerlas nuevamente en marcha después de una falla. Todo esto sin importar los sistemas, ni los administradores de recursos. Surgen de la necesidad de correr aplicaciones capaces de atender a cientos o miles de clientes, ya que los monitores permiten conectar en tiempo real a miles de clientes que esperan un servicio, sin necesidad de consumir tantos recursos. Ejemplo: si un cliente necesita para ser atendido de los siguientes recursos: 1 proceso, 1 conexión, ½Mb de RAM y una docena de archivos abiertos.

Cuando un cliente solicita un servicio, el monitor TP la destina aun proceso, el cual se enlaza con la función DLL llamada por el cliente, la invoca, supervisa su ejecución y regresa los resultados al cliente. Una vez concluido el trabajo el proceso servidor regresa los resultados y el proceso puede ser reutilizado por otro cliente. El SO conserva en memoria las DLL para que puedan ser compartidas por otros procesos.

Si el número de solicitudes de clientes recibidas excede el número de procesos en el servidor, el monitor puede iniciar dinámicamente otros nuevos (equilibrio de cargas). Parte del equilibrio de cargas es la administración de prioridades en las solicitudes recibidas, de esta forma solicitudes con prioridad alta se asignan a clases de servidor de alta prioridad. También el monitor de TP puede dividir sus clases de acuerdo al tipo de aplicación, tiempo de respuesta deseado, recursos que administran, requerimientos de tolerancia a fallas, etc.

A un monitor de TP lo podemos ver como una arquitectura cliente / servidor compuesta de tres planos: una interfaz gráfica GUI, la lógica de aplicación y los administradores de recursos.

BENEFICIOS DE UN MONITOR TP

Estructura de desarrollo de aplicaciones cliente/servidor. Los monitores TP proporcionan una estructura preconstruida que ayuda a formar, operar y administrar una aplicación cliente/servidor. Permite. construir aplicaciones cliente/servidor robustas y de alto desempeño. Muros de protección. Implementan muros de protección entre aplicaciones y administradores de recursos, así como entre las mismas aplicaciones. Alta disponibilidad. Los monitores TP están diseñados para sortear todo tipo de fallas, permite crear sistemas autoremediables, ya que siempre están al tanto del estado de los recursos de cliente / servidor bajo su control, pueden detectar una falla en el momento mismo que ocurren y decidir si reinicia el proceso fallido o retrocede y conmuta aun proceso en otro nodo. (arquitecturas sin un sólo punto de falla). Equilibrio de cargas. Los monitores de TP se especializan en la administración de procesos y soportan técnicas de carga tanto estáticas como dinámicas; soportan solicitudes con prioridad y pueden duplicar dinámicamente procesos del servidor en el mismo nodo o en otro diferente. Facilidad de ampliación de funciones. Los monitores TP alientan la creación de procedimientos modulares reutilizables. Los monitores sólo exportan las funciones y no los datos, así se podría seguir añadiendo nuevas funciones y permitir que el monitor de TP las distribuya entre múltiples servidores. De esta forma se podrían construir aplicaciones distribuidas de alta complejidad con sólo agregar procedimientos.

Costo reducido del sistema. De acuerdo a estudios, si se usan monitores de TP se puede ahorrar más del 30% del costo total del sistema, un 40% en costos de desarrollo y ahorros en la adquisición de recursos.

Generalmente, se recomienda usar un monitor de TP si su aplicación cliente / servidor tiene más de 100 clientes, que procesen cinco o más transacciones por minuto, emplee tres o más servidores y/o haga uso de dos o más BD.

Expand

Historia de las bases de datos en Ciencia de la Información

Para el desarrollo de éste estudio se tuvieron en cuanta las bases de datos en Ciencia de la Información de acuerdo a los siguientes aspectos:

  • Que las bases de datos sean de libre acceso y pública.
  •  Que recojan información de todo tipo de textos, especialmente de revistas tanto electrónicas como en formato impreso.
  • Una cobertura y características suficientes como para dar respuesta a las peticiones de búsquedas más comunes.
  • Se ha hecho especial hincapié en recopilar todas aquellas que tengan contenidos en español.

A continuación, se exponen brevemente los inicios y la evolución de algunos de los bases de datos importantes:

 

LISA - Library and Information Science Abstracts

LISA tiene una perspectiva internacional con una audiencia diversa incluyendo investigadores, estudiantes y profesionales de la información. Desde su inicio en 1969, LISA ha desarrollado una amplia gama de información relacionada con la bibliotecología, las teorías y practicas de la Ciencia de la Información (LIS) Library Information Science, cubriendo gran variedad de publicaciones.

 

METABASE

Desde 1973 se inician las gestiones para la creación del Colegio de Bibliotecarios de Costa Rica. La bibliotecaria Nelly Kopper asistió a un curso de la Universidad de Panamá donde fue designada, en una reunión conjunta entre los bibliotecarios centroamericanos y los profesores de dicho curso, para fundar una asociación de bibliotecarios costarricenses.

La Fundación Acceso, formuló un proyecto para consolidar la biblioteca electrónica especializada en medio ambiente y desarrollo sostenible para Centroamérica denominada MetaBase. Esta iniciativa fue sometida a consideración del programa INFODEV del Banco Mundial en el año 1996-1997. El proyecto fue aprobado en los siguientes dos años y su ejecución inició en el mes de julio del año 2000.

MetaBase, al ser una base de datos en Internet que contiene el conjunto total de registros bibliográficos de múltiples centros de información, le permite al usuario final realizar búsquedas de material bibliográfico, en forma simultánea, en todas las bases de datos de los centros participantes. El resultado de la búsqueda es una lista de los materiales relevantes y la referencia bibliográfica completa de cada uno de ellos

Es una poderosa herramienta de investigación que permite a los usuarios finales acceder y ubicar con facilidad recursos bibliográficos disponibles en diversas bibliotecas y centros de documentación en Centroamérica.

 

BEDOC

Elisa García-Morales y Carlota Bustelo Ruesta iniciaron junto con otros profesionales en el año 1984 el Gabinete de Asesores Documentalistas, empresa dedicada a prestar servicios en el área de la documentación. En 1996 crean Inforárea como parte de una reorientación estratégica que surge de las necesidades del mercado. Es así como dentro de sus productos internos crean BEDOC como una base de datos bibliográfica con toda la información referente a los temas que consultan. Cada trimestre se actualiza la información que tienen en su base de datos y permiten el acceso libre a los registros que contienen.

 

DOAJ - Directory of Open Acces Jounals

El Directorio de Revistas Open Access (Directory of Open Acces Jounals, DOAJ), fundado por el Open Society Institute - Budapest, es el directorio más amplio existente en Internet de revistas open access. Reside en las bibliotecas de la Universidad de Lund y está financiado por la coalición SPARC, SPARC Europa, BIBSAM, Axiell. DOAJ se ha puesto en ejecución en dos fases. Durante la primera, se estableció el directorio en sí mismo. La fase dos en el 2003 comenzó desarrollado un sistema comprensivo en la búsqueda de contenidos a nivel de artículos, de esta manera el sistema de búsqueda tuvo que proveerse de meta datos para la localización más descriptiva de la información. En el área de Ciencia de la Información (library Information Science) se encuentran indexadas 60 revistas de libre acceso, las cuales en su mayoría son de universidades, asociaciones y profesionales alrededor del mundo. El objetivo del Directorio de revistas Open Access (DOAJ) es incrementar la visibilidad y fomentar el uso de la literatura científica a través de las revistas científicas y académicas. La iniciativa Open Acces se define como un modelo en el que el acceso a la literatura científica de las revistas pertenecientes al DOAJ es gratuito tanto para los usuarios como para sus organizaciones.

 

ISOC - Biblioteconomía y Documentación

En la década de los 70, y como consecuencia del informe de la OCDE (Organización de Cooperación y Desarrollo Económico) sobre la política española en materia de información y documentación, se crea un órgano coordinador del Plan Nacional de Información Científica y Técnica como rector de todas estas actividades, con el nombre de Centro Nacional de Información y Documentación Científica (CENIDOC). El CENIDOC coordinaba tres Institutos orientados sobre grandes áreas del conocimiento: Ciencia y Tecnología, Biomedicina y Ciencias Sociales y Humanidades. De esta forma, en 1975, el CID se convierte en el Instituto de Información y Documentación en Ciencia y Tecnología (ICYT). En el mismo año, se crea, en el CSIC, el Instituto de Información y Documentación en Ciencias Sociales y Humanidades (ISOC), a partir del Departamento de Información Científica y Técnica del Instituto Bibliográfico Hispánico del Ministerio de Cultura. De igual forma se crea el de Biomedicina, sobre el Centro de Documentación e Informática Médica de Valencia.

La actuación de estos tres Institutos se basa en tres elementos fundamentales: investigación, docencia y servicios en el área de la Información y la Documentación Científica. Durante el año de 1975 se instalan en el ICYT y el ISOC, los primeros terminales para el acceso en línea a los grandes distribuidores de información: DIALOG, QUESTEL, ORBIT, etc. El ISOC publica por primera vez, en 1976, el ÿndice Español de Humanidades y el ÿndice Español de Ciencias Sociales. El ICYT inicia, en 1979, la edición del ÿndice Español en Ciencia y Tecnología. Estos tres ÿndices recogen, en forma de referencia bibliográfica y en sus respectivas áreas, los artículos publicados en las revistas científicas españolas y darán lugar a las Bases de Datos ISOC e ICYT respectivamente. En 1989 las Bases de Datos ICYT, de Ciencia y Tecnología, e ISOC, en Ciencias Sociales y Humanidades, empiezan a distribuirse en línea desde el Centro Técnico de Informática del CSIC. Las Bases de Datos del CSIC fueron, en 1990, el primer producto de información bibliográfica editado en CD-ROM. En 1992 se crea el Centro de Información y Documentación Científica (CINDOC) como resultado de la fusión del Instituto de Información y Documentación en Ciencia y Tecnología (ICYT) y el Instituto de Información y Documentación en Ciencias Sociales y Humanidades (ISOC) que asume de forma integradora los objetivos de ambos para potenciar la información científica de alta calidad en todos los campos del conocimiento.

 

E - LIS - E- Prints in Library and Information Science

E-LIS es el archivo abierto con más documentos en Biblioteconomía y Ciencias de laInformación. Su propósito es poner a disposición de la comunidad científica el texto completo de documentos para que sean más visibles, accesibles, recuperables y útiles para cualquier usuario potencial con acceso a Internet. Además este servicio anima a los profesionales a que depositen sus documentos (publicados o no) en E-LIS para su acceso libre en Internet.

E-LIS es diferente de otras iniciativas similares en el sentido que está basado en el trabajo voluntario de profesionales en Biblioteconomía y Ciencias de la Información y Documentación y, a su vez, tiene una orientación no comercial. Se basa en el espíritu del open source initiative en informática en el que la gente trabaja conjuntamente en la construcción y desarrollo de un software que esta en el dominio público.

En este sentido, E-LIS recoge esta filosofía y la aplica en la construcción de una biblioteca digital gratuita. E-LIS es administrado por un equipo internacional de voluntarios compuestos de profesionales de países como: España, Italia, Estados Unidos de América, Bosnia y Herzegovina, Cuba, Croacia, Sudáfrica, India, Indonesia, Peru, Alemania, Nigeria, Brasil, Grecia, el Reino Unido o Serbia y Montenegro. Este fue formado en 2003 para el depósito de documentos en el área de las Ciencias de la Información (Library Information Science).

Es el primer e-servidor internacional en este tema y resultante del proyecto DoIS (documentos de RCLIS investigación en computación, bibliotecas y Ciencias de la Información, promovidos por el Ministerio Español de Cultura y recibidos por el equipo de AEPIC en los servidores del Conzorcio italiano Interuniversitario Lombardo por Elaborazione Automatica (CILEA). Actualmente se encuentra activa y se desarrolla como uno de las bases de datos de Open Acces de más acceso por los profesionales de la información.

 

DoIS - Documents and Information Science

El origen de DoIS se remonta hacia el año 2002 cuando un grupo interdisciplinario de bibliotecarios, economistas, diseñadoes, libreros... de diversas partes del mundo, tuvieron la iniciativa de recoger, organizar y difundir literatura gris en el ámbito de la Ciencia de la Información. DoIS es un recurso bibliográfico gratuito de textos científicos especializados en el área de la Documentación Científica, que usa un sistema facilitado por RcLIS6 (Research in Computing, Library and Information Science), basado en una arquitectura distribuida, en la cual el trabajo de descripción y organización de documentos se realiza igualmente de manera distribuida entre los participantes del sistema.

Uno de los esfuerzos fundamentales de DoIS ha sido lograr la mayor visibilidad de la información. Por ello y para ello se incluyo en el directorio de recursos de calidad de Google, especializado en Library and Information Science. Ésta se ve además favorecida por la utilización del metadato ReDIF (Research Documents and Information Format). Se trata de un formato flexible que puede ser fácilmente modificado a medida que vayan surgiendo nuevas necesidades. Por otro lado es lo suficientemente simple como para que pueda ser utilizado por personal no especializado.

El tipo de material que recopila DoIS son artículos de revista, procedentes de las revistas de mayor impacto internacional en el área de la Documentación: Journal of the American Society for Information Science and Technology, Journal of Information Science, Journal of Documentation, Library and Information Science Research... , así como las más importantes en el área de la documentación en lengua hispana (Revista Española de Documentación Científica, Boletín de la ANABAD, Boletín de la Asociación Andaluza de Bibliotecarios, Anales de la Documentación, El profesional de la Información, Biblos, Ciencia da Informação... También se incluyen los trabajos presentados a los más importantes congresos celebrados en todo el mundo sobre nuestra disciplina (IFLA, Northumbria, ... ). Y otros documentos de interés científico que se encuentran accesibles en la red, tales como normas, monografías, informes técnicos... También es importante destacar la destreza y rapidez en la actualización de la información contenida, respecto a otras bases de datos del mismo ámbito.

La sede central de DoIS10 se ubica en el servidor MIMAS de Manchester, donde se cargan los datos a través del servicio FTP (File Transport Protocol). DoIS utiliza el metadato ReDIF11 Resource Description Information Format), basado en el modelo IAFA, y el protocolo Guildford.

Actualmente DoIS proporciona información referencial y acceso público mediante enlaces a texto completo, a un total de 1202 artículos y 3662 documentos de congresos, de los cuales 8529 son directamente accesibles.

{
}
Expand

Diseño de Bases de Datos Distribuidas

El diseño de un sistema de base de datos distribuido implica la toma de decisiones sobre la ubicación de los programas que accederán a la base de datos y sobre los propios datos que constituyen esta última, a lo largo de los diferentes puestos que configuren una red de ordenadores. La ubicación de los programas, a priori, no debería suponer un excesivo problema dado que se puede tener una copia de ellos en cada máquina de la red (de hecho, en este documento se asumirá que así es). Sin embargo, cuál es la mejor opción para colocar los datos: en una gran máquina que albergue a todos ellos, encargada de responder a todas las peticiones del resto de las estaciones - sistema de base de datos centralizado -, o podríamos pensar en repartir las relaciones, las tablas, por toda la red. En el supuesto que nos decantásemos por esta segunda opción, ¿qué criterios se deberían seguir para llevar a cabo tal distribución? ¿Realmente este enfoque ofrecerá un mayor rendimiento que el caso centralizado? ¿Podría optarse por alguna otra alternativa? En los párrafos sucesivos se tratará de responder a estas cuestiones.

Tradicionalmente se ha clasificado la organización de los sistemas de bases de datos distribuidos sobre tres dimensiones: el nivel de compartición, las características de acceso a los datos y el nivel de conocimiento de esas características de acceso. El nivel de compartición presenta tres alternativas: inexistencia, es decir, cada aplicación y sus datos se ejecutan en un ordenador con ausencia total de comunicación con otros programas u otros datos; se comparten sólo los datos y no los programas, en tal caso existe una réplica de las aplicaciones en cada máquina y los datos viajan por la red; y, se reparten datos y programas, dado un programa ubicado en un determinado sitio, éste puede solicitar un servicio a otro programa localizado en un segundo lugar, el cual podrá acceder a los datos situados en un tercer emplazamiento. Como se comentó líneas atrás, en este caso se optará por el punto intermedio de compartición.


Respecto a las características de acceso a los datos existen dos alternativas principalmente: el modo de acceso a los datos que solicitan los usuarios puede ser estático, es decir, no cambiará a lo largo del tiempo, o bien, dinámico. El lector podrá comprender fácilmente la dificultad de encontrar sistemas distribuidos reales que puedan clasificarse como estáticos. Sin embargo, lo realmente importante radica, estableciendo el dinamismo como base, cómo de dinámico es, cuántas variaciones sufre a lo largo del tiempo. Esta dimensión establece la relación entre el diseño de bases de datos distribuidas y el procesamiento de consultas.

La tercera clasificación es el nivel de conocimiento de las características de acceso. Una posibilidad es, evidentemente, que los diseñadores carezcan de información alguna sobre cómo los usuarios acceden a la base de datos. Es una posibilidad teórica, pero sería muy laborioso abordar el diseño de la base de datos con tal ausencia de información. Lo más práctico sería conocer con detenimiento la forma de acceso de los usuarios o, en el caso de su imposibilidad, conformarnos con una información parcial de ésta.

El problema del diseño de bases de datos distribuidas podría enfocarse a través de esta trama de opciones. En todos los casos, excepto aquel en el que no existe compartición, aparecerán una serie de nuevos problemas que son irrelevantes en el caso centralizado.

A la hora de abordar el diseño de una base de datos distribuida podremos optar principalmente por dos tipos de estrategias: la estrategia ascendente y la estrategia descendente. Ambos tipos no son excluyentes, y no resultaría extraño a la hora de abordar un trabajo real de diseño de una base de datos que se pudiesen emplear en diferentes etapas del proyecto una u otra estrategia. La estrategia ascendente podría aplicarse en aquel caso donde haya que proceder a un diseño a partir de un número de pequeñas bases de datos existentes, con el fin de integrarlas en una sola. En este caso se partiría de los esquemas conceptuales locales y se trabajaría para llegar a conseguir el esquema conceptual global. Aunque este caso se pueda presentar con facilidad en la vida real, se prefiere pensar en el caso donde se parte de cero y se avanza en el desarrollo del trabajo siguiendo la estrategia descendente. La estrategia descendente debería resultar familiar a la persona que posea conocimientos sobre el diseño de bases de datos, exceptuando la fase del diseño de la distribución. Pese a todo, se resumirán brevemente las etapas por las que se transcurre.

Todo comienza con un análisis de los requisitos que definirán el entorno del sistema en aras a obtener tanto los datos como las necesidades de procesamiento de todos los posibles usuarios del banco de datos. Igualmente, se deberán fijar los requisitos del sistema, los objetivos que debe cumplir respecto a unos grados de rendimiento, seguridad, disponibilidad y flexibilidad, sin olvidar el importante aspecto económico. Como puede observarse, los resultados de este último paso sirven de entrada para dos actividades que se realizan de forma paralela. El diseño de las vistas trata de definir las interfaces para el usuario final y, por otro lado, el diseño conceptual se encarga de examinar la empresa para determinar los tipos de entidades y establecer la relación entre ellas. Existe un vínculo entre el diseño de las vistas y el diseño conceptual. El diseño conceptual puede interpretarse como la integración de las vistas del usuario, este aspecto es de vital importancia ya que el modelo conceptual debería soportar no sólo las aplicaciones existentes, sino que debería estar preparado para futuras aplicaciones. En el diseño conceptual y de las vistas del usuario se especificarán las entidades de datos y se determinarán las aplicaciones que funcionarán sobre la base de datos, así mismo, se recopilarán datos estadísticos o estimaciones sobre la actividad de estas aplicaciones. Dichas estimaciones deberían girar en torno a la frecuencia de acceso, por parte de una aplicación, a las distintas relaciones de las que hace uso, podría afinarse más anotando los atributos de la relación a la que accede. Desarrollado el trabajo hasta aquí, se puede abordar la confección del esquema conceptual global. Este esquema y la información relativa al acceso a los datos sirven de entrada al paso distintivo: el diseño de la distribución. El objetivo de esta etapa consiste en diseñar los esquemas conceptuales locales que se distribuirán a lo largo de todos los puestos del sistema distribuido. Sería posible tratar cada entidad como una unidad de distribución; en el caso del modelo relacional, cada entidad se corresponde con una relación. Resulta bastante frecuente dividir cada relación en subrelaciones menores denominadas fragmentos que luego se ubican en uno u otro sitio. De ahí, que el proceso del diseño de la distribución conste de dos actividades fundamentales: la fragmentación y la asignación. El último paso del diseño de la distribución es el diseño físico, el cual proyecta los esquemas conceptuales locales sobre los dispositivos de almacenamiento físico disponibles en los distintos sitios. Las entradas para este paso son los esquemas conceptuales locales y la información de acceso a los fragmentos. Por último, se sabe que la actividad de desarrollo y diseño es un tipo de proceso que necesita de una monitorización y un ajuste periódicos, para que si se llegan a producir desviaciones, se pueda retornar a alguna de las fases anteriores.