HTMLpointHTMLpoint HTMLpoint.com


 Una base de datos como ejemplo



Presentaremos ahora la estructura de la base de datos que se utilizará para los ejemplos de las siguientes lecciones. No se describirán las fases de análisis ni los modelos conceptuales y lógicoa que han sido necesarios para alcanzar tal estructura, desde el momento en que esto se apartaría de los objetivos de este curso. La estructura de la base de datos está representada en el diagrama relacional de la Figura 3. Cada rectángulo representa una relación. El nombre de la relación está en la sección más oscura de la parte alta del rectángulo. El resto del rectángulo está subdividido en tres columnas, en las cuales están definidas las características de los atributos que componen la relación. La columna central contiene los nombres de los atributos; la de la derecha, su tipo (han sido utilizados los tipos del SQL/92), y la de la izquierda sus propiedades, Las propiedades de los atributos se indican con las siglas "PK" y "FK", que significan respectivamente que los correspondientes atributos forman parte de la llave primaria de la relación (Primary Key) o de una llave externa (Foreign Key). Las flechas hacen converger las llaves externas con las primarias a las que se refieren. Los nombres de los atributos en negrita indican que éstos no pueden tomar el valor NULL, o sea que no pueden ser indeterminados.


La finalidad de la base de datos consiste en contener las informaciones bibliográficas de un conjunto de publicaciones, a fin de poderlas consultar fácilmente y utilizarlas para la construcción de otras bibliografías. Ésta se ha modelado en la falsa línea del sistema bibliográfico del sistema LaTeX, para contar con un ambiente consolidado al que referirse y facilitar la realización de programas de conversión entre un sistema y otro.
El significado de las relaciones que componen la base de datos es el siguiente:

Publication: Una publicación genérica. Normalmente, esta relación se usa sólo para asignarles un identificativo unívoco a todas las publicaciones presentes en la base de datos, dejando la especificación de las demás características en relaciones específicas para cada tipo de publicación. Además, se usa para implementar uniones complejas entre las publicaciones y otras relaciones. Por ejemplo, la que existe entre una publicación y su autor. Gracias a la estructura adoptada, se puede contar con publicaciones escritas de muchos autores y con autores que escriben diferentes tipos de publicaciones.

Author: Representa al autor de una publicación. La llave primaria está compuesta por el identificativo de la publicación y por el de la persona, lo que grantiza la unidad de la asociación entre las dos entidades.

Editor: Representa al coordinador de una publicación. La estructura es idéntica a la de la tabla Author.

Person: Representa a una persona (por ejemplo, un autor) en la base de datos. Actualmente, las informaciones consideradas interesantes son sólo el apellido y el nombre.

Publisher: La casa editorial de una publicación.

Institution: La institución (por ejemplo una universidad o una software house) responsable de una publicación.

Book: Un libro con una casa editorial precisa.

InBook: Una parte de un libro. La parte puede caracterizarse por un título, por el número del capítulo o por el de la página. Las informaciones a propósito del libro y, por tanto, comunes a sus diferentes partes, se memorizan en la relación Book.

Proceedings: Las actas de un congreso o de una conferencia.

InProceedings: Una parte de las actas de un congreso. Las informaciones referidas a la publicación que contiene esa parte están en la relación Proceedings.

Article: Un artículo publicado en un periódico o en una revista.

Manual: Una publicación de documentación técnica.

Techreport: Un informe técnico publicado por una escuela u otra institución.

Thesis: Una tesina o una tesis.

Misc: Una publicación que no puede englobarse en ninguna de las categorías anteriores.

No voy a explicar el significado de los atributos que componen las diferentes relaciones, puesto que sus nombres se explican por sí mismos. Sólo una anotación sobre el atributo "pub_month": se ha definido como de tipo CHAR(3), es decir una cadena con una longitud fija de tres caracteres que incluirá las abreviaturas de los nombres de los meses (las primeras tres letras de los nombres ingleses).

Los lazos entre las relaciones deberían ser bastante fáciles de entender. Como ejemplo para todos, usaremos el que conecta la relación Book con la relación Publisher. Este lazo sirve para describir la la editorial de un libro. En la relación Book no están presentes todos los datos de la editorial, sino sólo un identificativo numérico para ella. El número será la llave primaria de la relación Publisher y como tal permitirá identificar una editorial precisa. En la relación Book el atributo publisher es una llave externa hacia la relación Publisher.
Una situación más compleja es la que afecta a las relaciones Publication, Author y Person; efectivamente, en Author están presentes dos llaves externas: una que identifica la publicación a la que la instancia de relación se refiere, y otra que permite remontarse a los datos de la persona que desempeña el papel de autor. Se podría preguntar cuál es la utilidad de la relación Publication y por qué no se ha establecido directamente un nexo entre la relación Author y las relaciones que representan los tipos de publicación concretos. La respuesta es que el modelo relacional no permite hacerlo. En efecto, desde el momento en que un autor puede escribir diferentes tipos de publicación, el atributo pubblicationID debería ser una llave externa hacia todas las relaciones de las publicaciones, pero esto no está permitido desde el momento en que contradice la definición misma de llave externa.

En las siguientes lecciones se implementará la base de datos de ejemplo usando el lenguaje SQL estándar. El DBMS específico usado será PostgresSQL, pero se podrá sustituir con cualquier DBMS que soporte l'Entry level del SQL/92.


Torna a inizio pagina