UNA SUAVE INTRODUCCIÓN A LAS BASES DE DATOS RELACIONALES Y ORIENTADAS A OBJETOS

UNA SUAVE INTRODUCCIÓN A LAS BASES DE DATOS RELACIONALES Y ORIENTADAS A OBJETOS

Prefacio

A finales de 1995 formé parte de un grupo de trabajo que estaba a punto de embarcarse en un nuevo proyecto que eventualmente utilizaría una gran base de datos. Las personas del grupo provenían de diferentes orígenes y experiencias y por lo tanto, para asegurar que todos pudiéramos estar de acuerdo en los conceptos básicos y la terminología, me ofrecí para preparar una charla explicando los fundamentos de las bases de datos relacionales, uno de mis temas favoritos.

La charla fue muy bien recibida, por lo que me dieron el trabajo de averiguar acerca de las bases de datos orientadas a objetos e informar sobre eso también. Pasé un mes en la biblioteca haciendo una encuesta de literatura, al final de la cual compilé una bibliografía anotada y presenté una segunda charla.

Hice este material disponible en mi espacio de la tela y entonces, después de algunos meses, lo olvidé. Incluso terminé archivándolo en CD cuando tenía poca cuota de disco. Recientemente, gracias a un fanático correo de fanáticos, me di cuenta de que mis presentaciones se estaban utilizando en todo el mundo en conferencias universitarias de Austria a Australia. Por lo tanto, para hacerlos visibles a un público más amplio, ahora los estoy recopilando en un informe técnico de ORL, que es lo que debería haber hecho originalmente.

Este informe es una reproducción exacta1 de mi material de 1995. Consta de tres partes: una charla sobre bases de datos relacionales, una charla sobre bases de datos orientadas a objetos y una bibliografía comentada sobre bases de datos orientadas a objetos. Las charlas están pensadas como introducciones de una hora para un público de profesionales de la informática, que se supone que es técnicamente competente pero no está familiarizado con los temas tratados. No se asume ningún conocimiento previo de las bases de datos para la charla de la base de datos relacional, y haber absorbido la primera charla es una condición previa suficiente para entender la segunda. Sabiendo por experiencia que las diapositivas a menudo se sienten desnudas al ser reimpresas, las he aumentado con comentarios que hacen eco de lo que habrías oído de mí si hubieras estado presente en la charla.

Si desea utilizar o adaptar estas charlas como su propio material de capacitación, que puede hacer libremente siempre y cuando acredite la fuente y dé un puntero a mi página, las presentaciones Powerpoint correspondientes se pueden descargar gratuitamente desde http: // www. Orl.co.uk/~fms/db/. Ya que estoy trabajando en otros temas, no tengo planes de mantener la bibliografía actualizada. Sin embargo espero que usted encontrará este material útil como introducción y agradecer cualquier regeneración.

Cambridge, Reino Unido

Mayo de 1998

Una introducción a las bases de datos relacionales

Esta es una breve introducción al tema de las bases de datos relacionales. No requiere ningún conocimiento previo de los sistemas de bases de datos. Su objetivo es explicar lo que significa el calificador "relacional" y por qué las bases de datos relacionales son un hito importante en la tecnología de bases de datos.

Lectura adicional: Las bases de datos relacionales son ahora una tecnología bien entendida y madura y, como tal, están incluidas en cualquier texto de base de datos adecuado.

Un excelente y autoritario libro de texto es C. J. DATE, Una Introducción a los Sistemas de Bases de Datos, Addison-Wesley, ahora en su sexta edición (1995).

Varios ejemplos en esta charla vienen de la tercera edición (1981) de este libro.

¿Qué es una base de datos?

• archivos
• campos
• Archivo lineal de registros homogéneos

¿Cuál es la imagen que viene a la mente cuando hablamos de una base de datos? Por supuesto todos estamos familiarizados con conceptos como registros y campos. Así que una pila de cartas como la que se muestra arriba es tal vez su imagen mental de una base de datos.

Bueno, si lo es, por favor, ¡golpear con una gran cruz roja! Pensar en un archivo lineal de registros homogéneos como el arquetipo de una base de datos es tan reductivo como pensar en un monopatín como el arquetipo para un vehículo de carretera. Un archivo plano es sólo una forma muy, muy restringida de base de datos.

Una base de datos real suele ser un repositorio de información heterogénea pero interrelacionada.

El ejemplo anterior, inspirado en [Date 81], describe una empresa en la que hay empleados que trabajan en proyectos (ver la flecha) y donde los proyectos usan partes que son suministradas por proveedores (ver la flecha triple). También hay una flecha adicional entre los empleados y los proyectos para representar otra relación, a saber, que algunos empleados son gerentes a cargo de algunos proyectos. En esta etapa no vamos a entrar en detalles sobre cómo esta información y estas interconexiones se almacenan realmente en la base de datos: simplemente estamos observando que una base de datos es un objeto bastante más complejo que el archivo plano que vimos en la diapositiva anterior.

Una de las propiedades más típicas de la base de datos es su capacidad para responder a consultas complejas anidadas como la que se muestra arriba.

¿Qué es una base de datos relacional?

Soporta la estructura de datos relacionales

Tiene un lenguaje de manipulación de datos al menos tan poderoso como el álgebra relacional

Hemos acordado, al menos en un nivel muy general, en lo que es una base de datos. Ahora bien, ¿cuál es el significado del calificativo "relacional"?

Esta diapositiva presenta una definición formal, pero la terminología no tiene mucho sentido todavía, así que tendremos que hacer una digresión y luego volver a esta definición más adelante.

Por el momento, tenga en cuenta que hay dos requisitos: uno sobre la estructura de datos y otro sobre el DML.

El DML, por cierto, es el lenguaje de programación utilizado para expresar operaciones que interrogan o actualizan la base de datos. La consulta en lenguaje natural de la diapositiva anterior, por ejemplo, tendría que ser traducida al DML de la base de datos antes de ser ejecutada.

Ejemplo de db relacional

Términos y conceptos:

• Tupla
• dominio
• atributo
• llave
• Reglas de integridad

Los términos y conceptos básicos de las bases de datos relacionales pueden explicarse con más facilidad si se hace referencia a un ejemplo (éste se toma prestado de [Fecha 81]).

Los proveedores se almacenan en una tabla llamada S (superior izquierda); Cada fila de la tabla representa un proveedor. La tabla es de hecho equivalente al archivo plano obsoleto de registros homogéneos de nuestra diapositiva de apertura, con cada fila siendo un registro y cada columna siendo un campo. Tenga en cuenta, sin embargo, que toda la base de datos está compuesta por varias tablas, no sólo una. Hay una tabla P para las piezas y una tabla SP que nos dice qué partes, y en qué cantidad, son suministradas por el proveedor. (La tabla SP representa así una de las "flechas" en el diagrama abstracto que vimos anteriormente, mientras que las tablas S y P representan "rectángulos llanos" - si esta descripción algo floja tiene sentido para usted.) Cada fila es esencialmente una lista de N valores (n es el número de columnas de la tabla), o una n-tupla en términos matemáticos. La llamamos una tupla para abreviar.

Cada columna representa un campo del registro y se llama un atributo.

El contenido de cada atributo (por ejemplo, el atributo "color" de una parte) sólo puede tomar valores de un conjunto dado; Este conjunto de valores admisibles para una columna se denomina dominio.

Una clave es un atributo o combinación de atributos que identifica de forma única una fila. Por ejemplo, el atributo P # (número de pieza) identifica de forma única la parte, en el sentido de que, dado un número de parte, hay como máximo una parte (una tupla) que coincide con el número de parte. El color de la parte no identifica de forma única la parte, ya que podría haber dos partes con el mismo color. Tenga en cuenta que calificar un conjunto de atributos como una clave es una decisión semántica que sólo se puede tomar con conocimiento del significado de los datos en la base de datos; No se puede inferir simplemente mirando la instancia actual de la base de datos. Si, por ejemplo, en un momento dado no hubiera dos partes con el mismo color, el atributo de color todavía no sería una clave válida para la tabla P, siempre que exista la posibilidad de que las partes con el mismo color que Otras partes se insertan posteriormente en la base de datos. Observe también el caso de la tabla SP donde ningún atributo puede ser clave: el par S # - P # tiene que ser tomado como clave.

Obsérvese cómo cada tupla en la tabla SP se refiere a una tupla en S ya una tupla en P por medio de sus respectivas claves. Seguramente una referencia a, por ejemplo, el proveedor S1, no tendría ningún sentido si no hubiera ninguna tupla S1 en la tabla S. Las reglas de integridad expresan restricciones que la base de datos debe satisfacer para ser internamente consistentes; Una regla de este tipo, llamada integridad referencial, es que las tuplas en SP sólo pueden referirse a las tuplas en S y P que realmente existen. Como consecuencia de esto, cuando se elimina un proveedor, se debe asegurar que, además de su supleción, se eliminen también todas las tuplas SP referentes a sus envíos.

...