BLOQUE 3 (I): BASES DE DATOS RELACIONALES 3.1. – BASES DE DATOS RELACIONALES El modelo de base de datos relacional fue introducido por Codd en 1970, este modelo persigue los siguientes objetivos: Independencia física: el modo en el que se almacenan los datos (modelo físico), no influye en su manipulación lógica, por tanto los usuarios que acceden a esos datos no tienen que modificar sus programas (software) cuando se efectúen cambios en el almacenamiento físico. Independencia lógica: de modo que la modificación de los elementos que componen la base de datos no debe repercutir en los programas y/o usuarios que manipulan los subconjuntos parciales de datos (vistas). Flexibilidad: cada usuario recibe los datos en el formato que desea con independencia de los formatos de los demás usuarios. Uniformidad: las estructuras lógicas de los datos presentan un aspecto uniforme, que facilita la concepción y manipulación de la base de datos por parte de los usuarios. Sencillez: el modelo de datos relacional es muy intuitivo y sencillo de modo que resulta de fácil comprensión y utilización al usuario. Sólido fundamento teórico: desde las propuestas iniciales de los artículos de Codd el modelo ha sido desarrollado y ampliado, pero sus bases iniciales continúan inalterables lo que da idea de la validez de su fundamento. 3.2. – CONCEPTOS BÁSICOS El modelo relacional está basado en la teoría matemática de las relaciones, que se construye a partir de la teoría de conjuntos. La relación es el elemento básico del modelo relacional y se representa por medio de una tabla bidimensional compuesto por filas (a las que denominaremos tuplas) y columnas (a las que denominaremos atributos). Ejemplo de una relación: Nos_VEN DEDOR NOMBRE PAISES VENTAS A REALIZAR D O M I N I O VENTAS R E L A C I O N NUM_VENDED OR 1 2 3 4 5 NOMBRE PEREZ DIAZ GOMEZ LOPEZ GARCIA AREA DE VENTAS MADRID PARIS LONDRES SUECIA BARCELONA OBJETIV O 20000 25000 15000 40000 10000 ATRIBUTOS T U P L A S GRADO (3) En resumen: Nombre de la relación: VENTAS Relación: Tabla Dominios: Nos_VENDEDOR, NOMBRES, PAISES, VENTAS A REALIZAR Atributos: NUM_VENDEDOR, NOMBRE, AREA DE VENTAS, OBJETIVO Tuplas: Filas de la relación Cardinalidad: Número de tuplas Grado: Número de atributos distintos Siguiendo este ejemplo vamos a definir los conceptos básicos que se manejan en la teoría de las bases de datos relacionales. Dominio: Conjunto finito de valores del mismo tipo caracterizado por un nombre e indivisibles (atómicos). Se pueden definir por extensión enumerando uno a uno los valores que toma dentro del rango en que esté definido, o por compresión indicando una propiedad característica de los valores del dominio. Por ejemplo si es de tipo entero, real, booleano, alfanumérico o de caracteres, etc. Hay dos tipos de dominios: C A R DI N A LI D A D o Generales (ó continuos): contienen todos los valores entre un mínimo y un máximo. Por ejemplo los DNI enteros 8 dígitos o Restringidos (o discretos): contienen ciertos valores entre un mínimo y un máximo. Por ejemplo los DNI que comienzan por los dígitos 13. o Es de uso común asignar el mismo nombre al atributo y al dominio en el que está definido aunque en el caso de que sean varios atributos de una misma tabla los que estén definidos sobre el mismo dominio habrá que asignarles nombres distintos. Por ejemplo en el dominio de los precios de artículos el precio de compra y el precio de venta. o Dominio compuesto: En los últimos trabajos de Codd y Date se introduce el concepto de dominio compuesto como una combinación de dominios simples que tiene un nombre y a la que se pueden aplicar ciertas restricciones de integridad. Por ejemplo, el dominio compuesto Fecha que está compuesto por los tres dominios simples Día, Mes y Año, el dominio Nombre que puede estar compuesto por los dominios simples Nombre y Apellido... o También se puede definir un atributo compuesto, sería aquel que toma valores dentro del dominio compuesto del mismo nombre. Producto cartesiano: Se denomina producto cartesiano entre dos dominios (simples), D1 y D2, al conjunto de todos los pares que se pueden formar tomando un elemento del primer dominio y otro del segundo. En el ejemplo anterior tomando el dominio VENDEDOR y AREA DE VENTAS: Pérez, Madrid Díaz, Madrid Gómez, Madrid López, Madrid García, Madrid Pérez, París Díaz, París Gómez, París López, París García, París Pérez, Londres Díaz, Londres Gómez, Londres López, Londres García, Londres Pérez, Suecia Díaz, Suecia Gómez, Suecia López, Suecia García, Suecia Pérez, Barcelona Díaz, Barcelona Gómez, Barcelona López, Barcelona García, Barcelona Relación: es un subconjunto del producto cartesiano de una lista de dominios, no necesariamente distintos, caracterizada por un nombre. o La relación se representa de una forma muy sencilla, por medio de una tabla de dos dimensiones, por lo que formalmente una relación es un conjunto de filas en la terminología relacional. En ella cada fila corresponde a un vector del producto cartesiano, mientras que cada columna corresponde a un dominio. o Para poder distinguir las columnas de una relación y poder darles un orden cualquiera, es necesario asociar un nombre a cada columna. Cada columna no es un dominio sino que toma valores (todos los posibles o sólo algunos) dentro de éste de modo finito. o En el ejemplo se puede establecer una relación entre los vendedores que hayan alcanzado objetivos superiores a 30000. Del dominio de todos los valores de nombres y del dominio de todos los enteros se toman únicamente aquellos pares del producto cartesiano VENDEDORES, OBJETIVOS, que cumplen la condición impuesta. Atributo: es la columna de una relación que representa una propiedad de la misma y que está caracterizada por un nombre. Un atributo toma sus valores finitos dentro del dominio. En el ejemplo de la relación VENDEDORES-OBJETIVOS, VENDEDORES será un atributo y OBJETIVOS otro. Características: Sólo pueden tomar valores en un dominio. Un mismo dominio puede utilizarse con varios atributos. Un atributo en una relación ha de ser único. Tupla: fila o línea de una relación correspondiente a un registro. o Como una relación se puede establecer entre varios dominios una relación n-aria corresponde a un conjunto de n-tuplas y se representa mediante un grafo entre los dominios de los atributos correspondientes. En el ejemplo se puede establecer la relación entre los VENDEDORES, PAIS, OBJETIVOS, que llamaremos AMBITO y que quedaría representada por el siguiente grafo: PEREZ MADRID DIAZ PARIS GOMEZ LONDRES LOPEZ SUECIA GARCIA PRAGA 10000 15000 20000 25000 30000 Tabla: es la representación de cualquier relación. o Las tablas permiten ver la información de forma compacta y tendrá una columna para cada atributo de los objetos o entidades descritas. Las filas estarán formadas por el conjunto de valores para cada atributo de una ocurrencia. En términos de ficheros las filas son lo que se conoce como registro y las columnas los campos del registro. o A las tablas se les puede aplicar la teoría del álgebra relacional pero siempre que cumplan determinados requisitos. o Un sistema de BD relacional no es cualquier sistema que maneja tablas, sino que dentro de los que manejan tablas han de cumplir los requisitos siguientes: La tabla sólo puede tener un mismo tipo de tuplas con un número fijo de atributos cada uno de los cuales identificado por un nombre. Las distintas relaciones entre los elementos de la BD darán lugar a distintas tablas cada una cumpliendo el requisito anterior. Dentro de una misma tabla cada atributo ha de ser distinto y no se permiten grupos repetitivos aunque tomen valores en el mismo dominio. Cuando a lo largo del proceso surgen grupos repetitivos en una tabla, habrá que volver a rediseñar el proceso y es posible que dé lugar a más tablas. Cada tupla ha ser única, no puede haber duplicidad en los valores de las tuplas. Las tablas son planas, es decir, el valor para un atributo de una tupla ha de ser único. Por tanto en el cruce de una fila y de una columna el valor es único. Las distintas tuplas no tienen porqué seguir un orden a no ser que se especifique en la creación de las tablas (sí se especifica el orden, esto sólo tiene sentido en el modo de presentación de salida de las tablas, no en la organización interna de éstas). Si la pérdida del orden supone pérdida de información es que la BD no está bien diseñada o que sus tablas (relaciones) están mal creadas. Nota: hay que tener en cuenta en que aunque una relación se puede representar como una tabla tiene una serie de elementos característicos que la distinguen de ésta: – No puede haber filas duplicadas – El orden de las filas es irrelevante – Cada celda, cruce de una fila con una columna, sólo puede tener un valor. Grado: número de atributos de que consta la tabla. Cardinalidad: Es el número de tuplas que integra la tabla y varía mucho a lo largo de los procesos asociados a la aplicación que soporta la BD. Asociaciones de relaciones: dos o más relaciones pueden estar a su vez relacionadas entre sí a través de uno o varios atributos. Por ejemplo en el ejemplo de VENTAS, la relación que puede existir entre la tabla VENTAS y la tabla VENDEDOR en la que se encuentran los datos de los vendedores. Claves: una clave es, un atributo o incluso un conjunto mínimo de atributos, que permiten el acceso y utilización de las tablas y son elementos de referencia que sirven para identificar, distinguir y acceder a las tuplas. Como son elementos fundamentales para el proceso de datos, las bases de datos, tanto las relacionales como las demás, incorporan facilidades y utilidades que hacen más sencillo su manejo. o La clave ha de ser única para cada tupla, y por tanto podemos decir que una clave posible o candidata es aquella formada por uno o más atributos que hace que cualquier tupla sea distinta de cualquiera otra de la tabla, por tanto la identifica unívocamente. En el ejemplo VENDEDORES, el NUM_VENDEDOR es clave ya que identifica totalmente a cada fila de la tabla. Clave primaria: es una clave candidata en la que ningún valor del/os atributo/s componentes puede ser nulo. Como en ocasiones la clave primaria de una tabla puede estar formada por atributos de otra tabla (referencia cruzada), se ha de llevar un seguimiento total de los valores que toma puesto que la introducción, borrado o actualización en general de la tabla puede implicar la necesidad de modificaciones en otras tablas. Claves secundarias o alternativas: es una clave candidata que no se ha elegido como clave primaria porque se realizan menos accesos a la tabla a través de dicho clave o bien es de más difícil manejo que la clave primaria. Claves ajenas: son el/los atributo/s de una tabla que es clave primaria para otra tabla referenciada. La clave ajena y su correspondiente clave primaria deben tomar valores sobre el mismo dominio. 3.3.- RESTRICCIONES En el modelo relacional existen restricciones, esto significa que hay estructuras u ocurrencias de datos que no están permitidas, vamos a distinguir entre las restricciones inherentes al modelo y las restricciones impuestas por el usuario. Restricciones inherentes al modelo relacional: No puede haber dos tuplas iguales. El orden de las tuplas no es significativo. El orden de las columnas no es significativo. Cada atributo de cada tupla solamente puede tomar un valor en el dominio que tiene asociado. Regla de la integridad de la entidad: Ningún atributo que forma parte de la clave primaria de una relación puede tomar valor nulo, desconocido. Restricciones de usuario: Son condiciones que se imponen sobre los atributos, ocurrencias o dominios como consecuencia de las características del sistema que estamos manejando y que hacen válidos o no los objetos del sistema: Integridad referencial: Si una relación R2 tiene un atributo (clave ajena), que es la clave primaria de otra relación R1, los valores que tome ese atributo en R2 deben ser iguales a los que existen para la clave primaria de R1 o ser nulos. Cuando se definen las claves ajenas hay que determinar las consecuencias que tienen las operaciones de borrado y modificación sobre las tuplas de la relación referenciada, en general existen las siguientes opciones: Operación restringida (RESTRICT): el borrado o la modificación de tuplas en la relación que contiene la clave primaria, solo se permite si no hay tuplas con dicha clave ajena en la otra relación. Operación con puesta a nulos (SET NULL): el borrado o modificación de tuplas en la relación que contiene la clave primaria, implica la puesta a nulos de los valores de las claves ajenas en la otra relación. Operación con transmisión en cascada (CASCADE): el borrado o modificación de tuplas en la relación que contiene la clave primaria, lleva implícito el borrado o modificación en cascada de las tuplas de las relaciones dependientes. Operación con puesta a un valor por defecto (SET DEFAULT): el borrado o la modificación de tuplas en la relación que contiene la clave primaria, conlleva a poner el valor por defecto indicado en las claves ajenas de las relaciones dependientes. Este valor por defecto se habría indicado al crear la tabla. Operación que desencadena un procedimiento de usuario (DISPARADORES): el borrado o modificación de tuplas en la tabla referenciada pone en marcha un procedimiento definido por el usuario. La opción que se selecciona en el caso de borrado y en el caso de modificación son independientes. Ejemplo: dadas las siguientes relaciones: EDITORIAL (NOMBRE_E, DIRECCION, CIUDAD, PAIS) LIBRO (CODIGO, IDIOMA, ......, NOMBRE_E) Donde NOMBRE_E es clave primaria de EDITORIAL y foránea de LIBRO Operación RESTRICT: el borrado o modificación del nombre de una editorial se podría realizar si no hubiera ningún libro editado en ella, en otro caso se impide la realización de la operación. Operación SET NULL: el borrado o modificación del nombre de una editorial implicaría que los atributos NOMBRE_E de las tuplas de LIBRO relacionadas con las tuplas que se han borrado o modificado, tomarían el valor nulo. Para que esta opción se pueda realizar las claves ajenas no pueden ser NOT NULL. Operación CASCADE: el borrado o modificación del nombre de una editorial implica que cambien o se borren las tuplas de la relación LIBRO que están relacionadas con las tuplas actualizadas en la relación EDITORIAL. Restricciones de usuario (opcionales). Son las que define el usuario según la aplicación, que se definen entre atributos, tuplas, interrelaciones y dominios. El SGBD debe de proporcionar medios que permitan mantener la integridad referencial de la tabla sin obligar al administrador, analista o programador a ocuparse de estos temas. 3.4.- DEFINICIÓN DE LAS RELACIONES Y DEL ESQUEMA RELACIONAL Cualquier relación se podrá definir, indicando su nombre, la lista de atributos, los dominios de esos atributos (la mayoría de los sistemas actuales no almacenan el dominio) y las restricciones impuestas por el sistema concreto a cada uno de ellos: R (A:D, S) El esquema relacional vendría dado por la descripción de cada una de las relaciones de la base de datos y las referencias que hay entre ellas. Esquemas y subesquemas: La arquitectura de una BD relacional está soportada en tres niveles: Nivel externo o submodelo de datos o vista: que corresponde al conjunto de tablas “ficticias” (tablas que no tienen existencia propia sino que derivan de una o más tablas base) a las que puede acceder un usuario. A este nivel se denomina subesquema a las declaraciones que describen el submodelo. Nivel conceptual o modelo de datos: que corresponde por todo el conjunto de las tablas relacionales (denominadas tablas base persistentes) almacenadas en la BD. En este nivel se denomina esquema al conjunto de declaraciones que describen el modelo. Nivel interno: corresponde a un modelo lógico en el que cada registro se corresponde con una tupla de las tablas base, pero no existe una correspondencia biunívoca ya que un registro puede estar formado por varias tuplas de distintas relaciones o una tupla puede dividirse en varios registros. Las tablas se representan por ficheros con un número cualquiera de índices asociados.