Diseño de BD Marc21

[Carlos Acevedo]

Hola a todos, mi nombre es Carlos Acevedo y soy estudiante de Ingenieria de Sistemas en Colombia. Como parte de mi trabajo de grado estoy estandarizando la biblioteca de mi universidad al sistema de catalogacion MARC 21 (IBERMARC en nuestro caso), parte del trabajo es diseñar un sistema de catalogacion automatizado, para ello estoy en la fase de diseño de la Base de Datos gestora del sistema, sin embargo me he tropezado con un detalle que me parece dificil de abordar.

 

Los campos Marc tienen etiquetas, tanto los campos como las etiquetas pueden ser repetibles, de modo que si yo asumiera cada campo (Por ejemplo el 020) como una tabla de la BD me chocaria con el hecho de que alguna etiqueta (La $z en este caso - ISBN cancelado o no valido) es repetible, obligandome a crear un registro en la base de datos por cada etiqueta que desee agregar, sin embargo esto no concuerda con la idea general de que lo UNICO repetible en ese campo seria solo esa etiqueta. Se me ocurrio crear una tabla por cada etiqueta pero eso me generaria un sistema muy dificil de diagramar y ademas con demasiadas tablas. La verdad no se me ocurre una solucion mas adecuada para la repetibilidad de las etiquetas en campos no repetibles, excepto ignorarla, pero entonces no estaria realizando una sistematizacion adecuada del sistema MARC.

 

Agradezco su atencion y ayuda, muchas gracias.

 

Carlos Acevedo

[Fernando Gómez]

On 2/27/07, Carlos Acevedo <carlosf...@gmail.com> wrote:

> Los campos Marc tienen etiquetas, tanto los campos como las etiquetas pueden
> ser repetibles, de modo que si yo asumiera cada campo (Por ejemplo el 020)
> como una tabla de la BD me chocaria con el hecho de que alguna etiqueta (La
> $z en este caso - ISBN cancelado o no valido) es repetible, obligandome a
> crear un registro en la base de datos por cada etiqueta que desee agregar,
> sin embargo esto no concuerda con la idea general de que lo UNICO repetible
> en ese campo seria solo esa etiqueta. Se me ocurrio crear una tabla por cada
> etiqueta pero eso me generaria un sistema muy dificil de diagramar y ademas
> con demasiadas tablas. La verdad no se me ocurre una solucion mas adecuada
> para la repetibilidad de las etiquetas en campos no repetibles, excepto
> ignorarla, pero entonces no estaria realizando una sistematizacion adecuada
> del sistema MARC.

Estimado Carlos:

El problema que planteas está claramente asociado al uso de un modelo
relacional para representar registros MARC. No tengo experiencia en el
uso de bases relacionales para trabajar con el formato MARC, sólo
tengo la idea, varias veces escuchada o leída por ahí, de que puede
volverse bastante complejo... pero eso ya lo sabías, ¿verdad? ;-).

Sin embargo, es posible que algún otro miembro del grupo te pueda orientar.

No sé cuánto has visto de Catalis, pero seguramente habrás notado que,
como trabaja con bases cds/isis, no hemos necesitado enfrentar esos
problemas.

Sí me gustaría aclarar una cuestión de terminología, para que sea más
fácil entenderse: lo que en tu mensaje llamas "etiquetas", en la jerga
de MARC (o de CDS/ISIS, o ISO 2709, para el caso es lo mismo) se
denominan "subcampos".

Saludos.

--
Fernando

[Tolousse]

Muchas gracias por tu atencion, la verdad no habia leido nada del
asunto de los modelos relacionales en MARC, la verdad es que si es muy
complejo llegar a representar los registros en el modelo que estoy
proponiendo, sin embargo de momento lo que se me ha ocurrido es crear
de forma manual los subcampos repetibles, es decir, para el caso del
campo 020 y el subcampo $z, crearia (por ejemplo) 3 espacios en la BD
z1, z2, z3 y con eso cumpliria con la idea de los subcampos
repetibles, sin embargo no se hasta que punto sea adecuado restringir
la repetibilidad a un numero fijo, no se que detrimento pueda causar
esto en la funcionalidad real del formato.

Una vez mas muchas gracias por la atencion.

Carlos Acevedo

On 27 feb, 10:38, "Fernando Gómez" <fjgo...@gmail.com> wrote:

[Fernando Gómez]

> proponiendo, sin embargo de momento lo que se me ha ocurrido es crear
> de forma manual los subcampos repetibles, es decir, para el caso del
> campo 020 y el subcampo $z, crearia (por ejemplo) 3 espacios en la BD
> z1, z2, z3 y con eso cumpliria con la idea de los subcampos
> repetibles, sin embargo no se hasta que punto sea adecuado restringir
> la repetibilidad a un numero fijo, no se que detrimento pueda causar
> esto en la funcionalidad real del formato.

Según mi (limitada) experiencia en catalogación, en muchos casos donde
se repiten subcampos basta con 2 o 3 ocurrencias. Hay sin embargo
casos donde la naturaleza del campo hace que sea muy probable tener un
número más alto de repeticiones, p.ej. los subcampos $t y $r en un
campo 505.

Quizás te sea útil ver cómo lo hace Koha, o algún otro de los sistemas
open source que hay por allí. Puedes encontrar varios en
http://oss4lib.org/article/applications.

Saludos.

--Fernando

[Luisen Velasquez]

Oye, creo que estoy en la misma situación que vos. ¿Podrías decirme cómo lo solucionaste? Te lo agradecería un montón. Esto del Marc21 me está rompiendo la cabeza.

[Luis Miguel Durá Orihuela]

Hola carlos . Mi nombre es Luis miguel  de venezuela, la idea que te planteo es que crees tablas donde cada registro represente un dato y no una columna como solemos hacerlos.

por ejemplo

tabla data marc

      codigo

      codigo marc

      entrada

      descripcion

.

.

.

alli guardarias todo tu catalogo marc

tendrias otra tabla donde guardaria tus catalogo propios ya que tu sistema no necesariamente tendria que guardar los mil campos marc.

tabla data catalogo

      codigo

      codigo marc

      entrada

      descripcion

.

.

.

 los que guardes aqui deben estar en 'data marc'

y otra tabla que contedria los datos como tal

dataCatalogo

   CODIGO

   codigomarc

   entrada

   metadata

y resultaria algo asi

 |codigo libro  | codigo    | codigomarc | entrada | metadata

 |  01 |0001    | 100   #1  | $a        | luis Siul   /* autor principal*/

 |  01 |0020    | 100   #1  | $b        | luis manuel /*autor principal*/

 |  01 |0030    | 100   #2  | $c        | luisa maria /*autor secundario*/

 |  01 |0027    | 100   #3  | $a        | luis miguel /*autor fotografo*/

 |  01 |0026    | 100   #3  | $b        | luis miguel /*autor diseñador*/

e igual seria con el titulo y todo los demas campos que estarian descritoen el catalogo marc para el libro '01' los campos que se repiten podrias guardarlos en otra tabla.

Voy a empezar a hacre para la universidad donde trabajo un sistema de biblioteca por lo que podriamos mantener contact y ayudarlos

[Gustavo Archuby]

Hola Carlos, hace varios años estuve trabajando en el tema y la realidad es que las bases de datos relacionales no están pensadas para trabajar con este tipo de formatos, trabajarlo de la forma tradicional te lleva a lo que vos estabas pensando, demasiadas tablas, lo que hace, cuando das de alta decenas miles de registros, que van a ser consultados por miles de usuarios a través de internet, que el rendimiento se caiga.

En aquella época se hizo una prueba sobre una base de datos con casi 100.000 registros sobre un sistema relacional desarrollado con informix y de hardware una Sun Microsystems, que era en velocidad varias veces una pc, contra una pc común con cds/isis y los mismos registros, la respuesta en la primera era de alrededor de 15 a 20 segundos mientras que en la segunda la respuesta era instantánea.

Otras implementaciones en lugar de tratar de representar el registro en una tabla, con referencias a los diferentes campos y subcampos, lo  que hicieron fue, tratando de explicar de la manera más sencilla posible, tener una tabla de subcampos donde cada registro de la la base relacional tiene los datos del subcampo, más, que ocurrencia es (subcampo repetible) a que campo pertenece el subcampo, a que registro pertenece el campo (teniendo en cuenta la repetibilidad). el tema es que luego hay que construir una lógica encima de esta estructura, ya que estamos utilizando un sistema relacional para algo para lo que no fué pensado, aunque termina siendo más eficiente en término de recursos al momento de realizar búsquedas.

Existen varios sistemas de bases de datos ducumentales, y muchas implementaciones de MARC son híbridos, es decir una parte está hecha con una bd relacional y otra con una bd documental u orientada a objetos.

Espero te haberte sido útil.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Catalis" group.
To post to this group, send email to cat...@googlegroups.com
To unsubscribe from this group, send email to catalis-u...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/catalis
-~----------~----~----~----~------~----~------~--~---