You are on page 1of 8

DATOS DE LA ASIGNATURA Nombre de la asignatura: Carrera: Clave de la asignatura: Horas teora-horas prctica-crditos Fundamentos de bases de datos Ingeniera en Tecnologas

informacin y comunicaciones AEF - 1031 3-2-5 de la

UNIDAD 3.MODELO RELACIONAL..................................................1


MODELO RELACIONAL................................................................................................................1 3.1ESTRUCTURA BSICA.............................................................................................................2 DEFINICIN DE RELACIN.........................................................................................................4 3.2CLAVES.......................................................................................................................................5 PROPIEDADES DE UNA RELACIN (GRADO, CARDINALIDAD).........................................6 3.3LENGUAJES DE CONSULTA...................................................................................................7 LENGUAJES FORMALES...............................................................................................................7 BIBLIOGRAFA...................................................................................................................................7
Competencia especfica a desarrollar Aplicar el modelo relacional para la generacin de esquemas de bases de datos.
Actividades de Aprendizaje

Analizar diferentes diagramas E-R. Proponer un ejemplo utilizando el modelo relacional. Elabora un reporte escrito con conclusiones respecto a los lenguajes de consulta. Elabora el diagrama relacional del proyecto de curso y entregar el avance.

UNIDAD 3.

MODELO RELACIONAL

MODELO RELACIONAL
Una base de datos relacional consiste en un conjunto de tablas, a cada una de las cuales se le asigna un nombre exclusivo. Cada tabla tiene una estructura parecida a la presentada en el tema anterior, donde se representaron las bases de datos E-R mediante tablas. Cada fila de la tabla representa una relacin entre un conjunto de valores. Dado que cada tabla es un conjunto de dichas relaciones, hay una fuerte correspondencia entre el concepto de tabla y el concepto matemtico de relacin, del que toma su nombre el modelo de datos relacional. A continuacin se introduce el concepto de relacin. En este captulo se utilizarn varias relaciones diferentes para ilustrar los conceptos subyacentes al modelo de datos relacional. Estas relaciones representan parte de una entidad bancaria. Se diferencian ligeramente de las tablas que se utilizaron en el tema anterior, por lo que se puede simplificar la representacin. En 1970, el modo en que se vean las bases de datos cambi por completo cuando E. F. Codd introdujo el modelo relacional. En aquellos momentos, el enfoque existente para la estructura de las bases de datos utilizaba punteros fsicos (direcciones de disco) para relacionar registros de distintos ficheros. Si, por ejemplo, se quera relacionar un registro con un registro, se deba aadir al registro un campo conteniendo la direccin en disco del registro. Este campo aadido, un puntero fsico, siempre sealara desde el registro al registro. Codd demostr que estas bases de datos limitaban en gran medida los tipos de operaciones que los usuarios podan realizar sobre los

datos. Adems, estas bases de datos eran muy vulnerables a cambios en el entorno fsico. Si se aadan los controladores de un nuevo disco al sistema y los datos se movan de una localizacin fsica a otra, se requera una conversin de los ficheros de datos. Estos sistemas se basaban en el modelo de red y el modelo jerrquico, los dos modelos lgicos que constituyeron la primera generacin de los SGBD. El modelo relacional representa la segunda generacin de los SGBD. En l, todos los datos estn estructurados a nivel lgico como tablas formadas por filas y columnas, aunque a nivel fsico pueden tener una estructura completamente distinta. Un punto fuerte del modelo relacional es la sencillez de su estructura lgica. Pero detrs de esa simple estructura hay un fundamento terico importante del que carecen los SGBD de la primera generacin, lo que constituye otro punto a su favor. Dada la popularidad del modelo relacional, muchos sistemas de la primera generacin se han modificado para proporcionar una interfaz de usuario relacional, con independencia del modelo lgico que soportan (de red o jerrquico). Por ejemplo, el sistema de red IDMS ha evolucionado a IDMS/R e IDMS/SQL, ofreciendo una visin relacional de los datos. En los ltimos aos, se han propuesto algunas extensiones al modelo relacional para capturar mejor el significado de los datos, para disponer de los conceptos de la orientacin a objetos y para disponer de capacidad deductiva. El modelo relacional, como todo modelo de datos, tiene que ver con tres aspectos de los datos: Estructura de datos. Integridad de datos. Manejo de datos.

3.1

ESTRUCTURA BSICA.

Considrese la tabla cuenta de la Figura 3.1. Tiene tres cabeceras de columna: nmero-cuenta, nombre-sucursal y saldo. Siguiendo la terminologa del modelo relacional se puede hacer referencia a estas cabeceras como atributos. Para cada atributo hay un conjunto de valores permitidos, llamado dominio de ese atributo. Para el atributo nombre-sucursal, por ejemplo, el dominio es el conjunto de los nombres de las sucursales. Supongamos que D1 denota el conjunto de todos los nmeros de cuenta, D2 el conjunto de todos los nombres de sucursal y D3 el conjunto de los saldos. Como se vio en el Captulo 2 todas las filas de cuenta deben consistir en una tupla (v1, v2, v3), donde v1 es un nmero de cuenta (es decir, v1 est en el dominio D1), v2 es un nombre de sucursal (es decir, v2 est en el dominio D2) y v3 es un saldo (es decir, v3 est en el dominio D3). En general, cuenta slo contendr un subconjunto del conjunto de todas las filas posibles.

Figura. 3.1 La relacin cuenta Por tanto, cuenta es un subconjunto de D1 D2 D3 En general, una tabla de n atributos debe ser un subconjunto de

D1 D2 Dn 1 Dn Los matemticos definen las relaciones como subconjuntos del producto cartesiano de la lista de dominios. Esta definicin se corresponde de manera casi exacta con la definicin de tabla dada anteriormente. La nica diferencia es que aqu se han asignado nombres a los atributos, mientras que los matemticos slo utilizan nombres numricos, utilizando el entero 1 para denotar el atributo cuyo dominio aparece en primer lugar en la lista de dominios, 2 para el atributo cuyo dominio aparece en segundo lugar, etctera. Como las tablas son esencialmente relaciones, se utilizarn los trminos matemticos relacin y tupla en lugar de los trminos tabla y fila. Una variable tupla es una variable que representa a una tupla; en otras palabras, una tupla que representa al conjunto de todas las tuplas. En la relacin cuenta de la Figura 3.1 hay siete tuplas. Supngase que la variable tupla t hace referencia a la primera tupla de la relacin. Se utiliza la notacin t[nmero-cuenta] para denotar el valor de t en el atributo nmero-cuenta. Por tanto, t[nmero-cuenta] = C-101 y t[nombresucursal] = Centro. De manera alternativa, se puede escribir t[1] para denotar el valor de la tupla t en el primer atributo (nmero-cuenta), t[2] para denotar nombre-sucursal, etctera. Dado que las relaciones son conjuntos se utiliza la notacin matemtica t r para denotar que la tupla t est en la relacin r. El orden en que aparecen las tuplas es irrelevante, dado que una relacin es un conjunto de tuplas. As, si las tuplas de una relacin se muestran ordenadas como en la Figura 3.1, o desordenadas, como en la Figura 3.2, no importa; las relaciones de estas figuras son las mismas, ya que ambas contienen el mismo conjunto de tuplas.

Figura 3.2 La relacin cuenta con las tuplas desordenadas Se exigir que, para todas las relaciones r, los dominios de todos los atributos de r sean atmicos. Un dominio es atmico si los elementos del dominio se consideran unidades indivisibles. Por ejemplo, el conjunto de los enteros es un dominio atmico, pero el conjunto de todos los conjuntos de enteros es un dominio no atmico. La diferencia es que no se suele considerar que los enteros tengan subpartes, pero s se considera que los conjuntos de enteros las tienen; por ejemplo, los enteros que forman cada conjunto. Lo importante no es lo que sea el propio dominio, sino la manera en que se utilizan los elementos del dominio en la base de datos. El dominio de todos los enteros sera no atmico si se considerase que cada entero fuera una lista ordenada de cifras. En todos los ejemplos se supondr que los dominios son atmicos. En el Captulo 9 se estudiarn extensiones al modelo de datos relacional para permitir dominios no atmicos. Es posible que varios atributos tengan el mismo dominio. Por ejemplo, supngase que se tiene una relacin cliente que tiene los tres atributos nombre-cliente, calle-cliente y ciudad-cliente y una relacin empleado que incluye el atributo nombre-empleado. Es posible que los atributos nombrecliente y nombre-empleado tengan el mismo dominio, el conjunto de todos los nombres de personas, que en el nivel fsico son cadenas de caracteres. Los dominios de saldo y nombresucursal, por otra parte, deberan ser distintos. Quizs es menos claro si nombre-cliente y nombre-sucursal deberan tener el mismo dominio. En el nivel fsico, tanto los nombres de clientes como los nombres de sucursales son cadenas de caracteres. Sin embargo, en el nivel lgico puede que se desee que nombre-cliente y nombre-sucursal tengan dominios diferentes.

Un valor de dominio que es miembro de todos los dominios posibles es el valor nulo, que indica que el valor es desconocido o no existe. Por ejemplo, supngase que se incluye el atributo nmero-telfono en la relacin cliente. Puede ocurrir que un cliente no tenga nmero de telfono, o que su nmero de telfono no figure en la gua. Entonces habr que recurrir a los valores nulos para indicar que el valor es desconocido o que no existe. Ms adelante se ver que los valores nulos crean algunas dificultades cuando se tiene acceso a la base de datos o cuando se actualiza y que, por tanto, deben eliminarse si es posible. Se asumir inicialmente que no hay valores nulos.

DEFINICIN DE RELACIN
Conjunto de tuplas del mismo esquema. Se forma de atributos, tuplas y dominios. Debe cumplir: - No hay tuplas duplicada - El orden de almacenamiento es irrelevante. - No hay columnas con nombres duplicados. Propiedades Grado: Numero de atributos Cardinalidad: Numero de tuplas

Matemticamente, una relacin se puede definir como un subconjunto del producto cartesiano de una lista de dominios, donde cada elemento de la relacin, tupla, es una serie de n valores ordenados. En esta definicin matemtica de relacin, que es la que aparece en los primeros trabajos de Codd, no se alude a los atributos, es decir, al papel que tienen los dominios en la relacin y, adems, en ella el orden de los valores dentro o de una tupla es significativo. A fin de evitar estos inconvenientes, se puede dar otra definicin de relacin ms adecuada al punto de vista de las bases de datos, para lo cual es preciso distinguir, dos conceptos en la nocin de relacin: Intensin o Esquema de relacin, denotado R (A1:D1, A2:D2, ..., An:Dn) es un conjunto de n pares atributo-dominio subyacente (Ai:Di). La intensin es la parte definitoria y esttica de la relacin, que se corresponde con la cabecera cuando la relacin se percibe como una tabla. Extensin u ocurrencia (instancia) de relacin (llamada a veces simplemente relacin), denotada por r(R) es un conjunto de m tuplas {t1, t2, ... tm} donde cada tupla es un conjunto de n pares atributo-valor.

Ejemplo: Intensin de una relacin: AUTOR (NOMBRE:Nombres, Instituciones) Extensin de una relacin: AUTOR Nombre Nacionalidad Pepe Espaa John EE.UU. Pierre Francia NACIONALIDAD:Nacionalidades, INSTITUCION:

Institucion O.N.U. O.M.S. N.A.S.A.

3.2

CLAVES

Una clave candidata de una relacin es un conjunto no vaco de atributos que identifican unvoca y mnimamente cada tupla. Por la propia definicin de relacin, siempre hay al menos una clave candidata, ya que al ser la relacin un conjunto no existen tuplas repetidas y por tanto, el conjunto de todos los atributos identificar unvocamente a las tuplas. Una relacin puede tener ms de una clave candidata, entre las cuales se debe distinguir: Clave primaria: es aquella clave candidata que el usuario escoger, por consideraciones ajenas al modelo relacional, para identificar a las tuplas de una relacin. Clave alternativa: son aquellas claves candidatas que no han sido elegidas.

Se denomina clave ajena de una relacin R2 a un conjunto no vaco de atributos cuyos valores han de coincidir con los valores de la clave primaria de otra relacin R1. La clave ajena y la correspondiente clave primaria han de estar definidas sobre los mismos dominios. RESTRICCIONES En el modelo relacional, existen restricciones, es decir, estructuras u ocurrencias no permitidas, siendo preciso distinguir entre restricciones inherentes y restricciones de usuario. Restricciones inherentes Adems de las derivadas de la definicin matemtica de "relacin" como eran que: No hay dos tuplas iguales. El orden de las tuplas no es significativo. El orden de los atributos (columnas) no es significativo. Cada atributo slo puede tomar un nico valor del dominio, no admitindose por tanto los grupos repetitivos.

Tenemos que la regla de integridad de entidad establece que "Ningn atributo que forme parte de la clave primaria de una relacin puede tomar un valor nulo"; esto es, un valor desconocido o inexistente. Esta restriccin debera aplicarse tambin a las claves alternativas, pero el modelo no lo exige. Restricciones de usuario Podemos considerar la restriccin de usuario, dentro del contexto relacional, como un predicado definido sobre un conjunto de atributos, de tuplas o de dominios, que debe ser verificado por los correspondientes objetos para que stos constituyan una ocurrencia vlida del esquema. Dentro de las restricciones de usuario destaca la restriccin de integridad referencial que dice que los valores de clave ajena deben coincidir con los de clave primaria asociada a ella o ser nulos. La integridad referencial es una restriccin de comportamiento ya que viene impuesta por el mundo real y es el usuario quien la define al describir el esquema relacional; es tambin de tipo implcito, ya que se define en el esquema y el modelo la reconoce (o as algunos productos) sin necesidad de que se programe ni de que se tenga que escribir ningn procedimiento para obligar a que se cumpla. EDITORIAL (NOMBRE_E, DIRECCION, CIUDAD, PAIS)

LIBRO (CODIGO, TITULO, IDIOMA, ..., NOMBRE_E) En este ejemplo el atributo nombre_e de la relacin LIBRO es clave ajena que referencia a EDITORIAL, de modo que debe concordar con la clave primaria de la relacin EDITORIAL o bien ser nulo, porque los libros de nuestra base de datos debern pertenecer a una editorial existente, o si se desconoce la editorial, no se tendr ningn valor para este atributo. AUTOR (NOMBRE, NACIONALIDAD, INSTITUCION, ..) LIBRO (COD_LIBRO, TITULO, IDIOMA, EDITORIAL, ...) ESCRIBE (NOMBRE, COD LIBRO) En este ejemplo la relacin ESCRIBE posee dos claves ajenas: nombre, que referencia a la relacin AUTOR, y cod_libro, que referencia a la relacin LIBRO; en este caso ninguna de las dos claves ajenas puede tomar valores nulos, ya que forman parte de la clave primaria de la relacin ESCRIBE. Adems de definir las claves ajenas, hay que determinar las consecuencias que pueden tener ciertas operaciones (borrado y modificacin) realizadas sobre tuplas de la relacin referenciada; pudindose distinguir, en principio, las siguientes opciones: Operacin restringida: esto es, el borrado o la modificacin de tuplas de la relacin que contiene la clave primaria referenciada; slo se permite si no existen tuplas con dicha clave en la relacin que contiene la clave ajena. Esto nos llevara, por ejemplo, a que para poder borrar una editorial de nuestra base de datos no tendra que haber ningn libro que estuviese publicado por dicha editorial, en caso contrario el sistema impedira el borrado. Operacin con transmisin en cascada : esto es, el borrado o la modificacin de tuplas de la relacin que contiene la clave primaria referenciada lleva consigo el borrado o modificacin en cascada de las tuplas de la relacin que contienen la clave ajena. En nuestro ejemplo, equivaldra a decir que al modificar el nombre de una editorial en la relacin EDITORIAL, se tendra que modificar tambin dicho nombre en todos los libros de nuestra base de datos publicados por dicha editorial. Operacin con puesta a nulos: esto es, el borrado o la modificacin de tuplas de la relacin que contiene la clave primaria referenciada lleva consigo poner a nulos los valores de las claves ajenas de la relacin que referencia. Esto nos llevara a que cuando se borra una editorial, a los libros que ha publicado dicha editorial y que se encuentran en la relacin LIBROS se les coloque el atributo nombre_e a nulos. Esta opcin, obviamente, slo es posible cuando el atributo que es clave ajena admite el valor nulo. Operacin con puesta a valor por defecto : esto es, el borrado o la modificacin de tuplas de la relacin que contiene la clave primaria referenciada lleva consigo poner el valor por defecto a la clave ajena de la relacin que referencia. Operacin que desencadena un procedimiento de usuario : en este caso, el borrado o la modificacin de tuplas de la tabla referenciada pone en marcha un procedimiento definido por el usuario.

PROPIEDADES DE UNA RELACIN (GRADO, CARDINALIDAD)


El nmero de filas de una relacin se denomina cardinalidad de la relacin y el nmero de columnas es el grado de la relacin. Ejemplo: AUTOR Nombre Pepe John Nacionalidad Espaa EE.UU. Institucion O.N.U. O.M.S.

Pierre

Francia

N.A.S.A.

Una relacin se puede representar en forma de tabla, pero va a tener una serie de elementos caractersticos: No puede haber filas duplicadas, es decir, todas las tuplas tienen que ser distintas. El orden de las filas es irrelevante. La tabla es plana, es decir, en el cruce de una fila y una columna slo puede haber un valor (no se admiten atributos multivaluados).

ESTUDIANTE(Nombre, Rut, Telfono, Direccin, Edad, Carrera, Prom-nota) tiene grado 7.

3.3

LENGUAJES DE CONSULTA

Concepto: Un lenguaje de consulta es un lenguaje en el que un usuario solicita informacin de la base de datos. Estos lenguajes son normalmente de ms alto nivel que los lenguajes comunes de programacin. Existen bsicamente 2 tipos de lenguajes de manipulacin de datos:

1. Lenguajes Procedimentales: Los LMD requieren que el usuario especifique que datos se
necesitan y cmo obtenerlos. En este tipo de lenguaje el usuario da instrucciones al sistema para que realice una serie de procedimientos u operaciones en la base de datos para calcular un resultado final.

2. Lenguajes No Procedimentales: Los LMD requieren que el usuario especifique que datos

se necesitan y sin especificar cmo obtenerlos. El usuario describe la informacin deseada sin un procedimiento especfico para obtener esa informacin.

LENGUAJES FORMALES.
Los lenguajes de consulta se usan para especificar las solicitudes de informacin La teora de lenguajes formales es en esencia un rea interdisciplinaria de la ciencia, que va desde la lingstica hasta la biologa. Los lenguajes formales constituyen una herramienta muy til para modelos de computacin, as como para otras ramas, tales como criptografa y la ingeniera. Por ejemplo, las entradas y salidas de un artefacto computacional, pueden ser vistas como lenguajes. Entre los lenguajes formales de bases de datos encontramos: 1. Algebra Relacional 2. Clculo Relacional 3. Optimizacin de Consultas

BIBLIOGRAFA 7

Silberschatz, Korth, Sudarshan, Fundamentos de bases de datos, cuarta edicin, Mc Graw-Hill, 2002,787 p. ABRAMHAM, KORTH y SUDARSHAN) (ELMASRI/NAVATHE)

You might also like