Institut Poblenou

Gins Plazas

MODELO RELACIONAL (MR)

1. HISTORIA:
Reseas histricas del Modelo Relacional de Datos(MRD): Aos 70: Propuesto por E. Codd en 1970. Est basado en dos ramas de las matemticas: la teora de conjuntos y la lgica de predicados de primer orden. (en aquellos momentos la estructura en las bases de datos se basaban en el modelo
de red y en el modelo jerrquico. El nuevo modelo de Codd constituye un intento de simplificar las estructuras de las bases de datos)

Aos 80: Se populariza en la prctica (Oracle, Informix, . . . ). ANSI define el estndar SQL. Aos 90: Generalizacin y estandarizacin (SQL92) y extensiones del mismo.

El Modelo Relacional es el modelo lgico en el que se basan la mayora de los SGBD comerciales en uso hoy en da.
Razones del xito: Sencillez, una base de datos es un conjunto de tablas. Modelo terico sobre el que se sustenta. Su base matemtica hace que el modelo sea predecible, fiable y seguro.
Actualmente para la mayora de las aplicaciones de gestin que utilizan bases de datos, el modelo ms empleado es el modelo relacional, por su gran versatilidad, potencia y por los formalismos matemticos sobre los que se basa.

En el modelo relacional debe abordarse los siguientes aspectos: La estructura de datos: Codd introduce el concepto de relacin como estructura bsica del modelo. Existen unas restricciones del modelo, la llamada integridad de datos. El manejo de datos: se refiere al conjunto de operadores que se aplican a las relaciones, es lo que denomina el lgebra relacional.

Institut Poblenou

Gins Plazas

2. Estructura de una base de datos relacional Terminologa.

En el Modelo Relacional, los datos estn estructurados (a nivel lgico) como TABLAS formadas por filas y columnas, (aunque a nivel fsico pueden tener una estructura completamente distinta)

RELACION ~ TABLA de datos, con columnas y filas

Las relaciones se utilizan para almacenar informacin sobre los objetos que se representan en la base de datos.
(relacion, es una terminologa perteneciente a las matemticas, en concreto de la teora de conjuntos y de la lgica de predicados )

Ejemplo: Tenemos 3 Relaciones (tablas), y en la parte inferior, el diagrama relacional que la representa.

Una relacin se representa grficamente como una tabla bidimensional en la que las filas corresponden a registros individuales (tambin llamadas tuplas) y las columnas corresponden a los campos o atributos de esos registros Un SGBD slo necesita que el usuario pueda percibir la base de datos como un conjunto de tablas (i.e. relaciones) (Esta percepcin slo se aplica a la estructura lgica de la
base de datos (en el nivel externo y conceptual de la arquitectura de tres niveles ANSI-SPARC). No se aplica a la estructura fsica de la base de datos, que se puede implementar con distintas estructuras de almacenamiento)

Institut Poblenou

Gins Plazas

Atributo (columna) es el nombre de una columna de una relacin. Los atributos pueden aparecer en la relacin en cualquier orden (es decir, importa el conjunto de los atributos, pero no en un orden especfico) Ejemplo: la relacin (tabla) EMPLOYEES, tiene los siguientes atributos: employee_id, first_name, last_name, email, phone_number, hire_date, salary, commission_pct Lo representamos de la siguiente manera (en modo texto):
EMPLOYEES (employee_id, first_name, last_name, email, phone_number,
hire_date, salary, commission_pct)

Tupla (fila, o registro) es una fila de la relacin. Son las ocurrencias de la relacin (sus instancias) y no siguen ningn orden. (es decir, importa el conjunto de las filas, pero no en un orden especfico) Ejemplo: Una Relacin (llamada Pelicula)

Cardinalidad: la cardinalidad de una relacin es el nmero de tuplas que contiene.

Ya que en las relaciones se van insertando y borrando tuplas a menudo, la cardinalidad de las mismas vara constantemente

Grado: El grado de una relacin es el nmero de atributos que contiene. Puede

variar pero no con tanta frecuencia como las tuplas.

Dominio: El dominio de un atributo es el conjunto de valores posibles de uno o varios atributos. Cada atributo de una base de datos relacional se define sobre un dominio, pudiendo haber varios atributos definidos sobre el mismo dominio. La siguiente tabla muestra los dominios de los atributos de la relacin OFICINA. Ntese que en esta relacin hay dos atributos que estn definidos sobre el mismo dominio, Telfono y Fax.

Institut Poblenou

Gins Plazas

Atributo
Onum Calle Area

Nombre del Dominio Descripcin

NUM_OFICINA NOM_CALLE NOM_AREA Posibles valores de nmero de oficina Nombres de calles de Espaa

Definicin
3 caracteres; rango O1-O99 25 caracteres

Nombres de reas de las poblaciones de Espaa 20 caracteres Nombres de las poblaciones de Espaa Nmeros de telfono de Espaa Nmeros de telfono de Espaa 15 caracteres 9 caracteres 9 caracteres

Poblacin NOM_POBLACION Telfono Fax NUM_TEL_FAX NUM_TEL_FAX

Independientemente del dominio que pertenezca, el atributo puede tomar un valor especial NULO (NULL) que designa la ausencia de datos (el dato es desconocido o inaplicable) Los dominios pueden ser de dos tipos: 1) Dominios predefinidos, que corresponde a los tipos de datos que normalmente proporcionan los lenguajes de bases de datos, como por ejemplo los enteros, las cadenas de caracteres, los reales, etc. 2) Dominios definidos por el usuario, que pueden ser ms especficos. Toda definicin de un dominio debe constar, como mnimo, del nombre del dominio y de la descripcin de los valores que forman parte de ste.

Valores Atmicos: En cada tupla, cada atributo toma un solo valor. Atmico significa indivisible; es decir, que por muy complejo o largo que sea un valor atmico, no tiene una estructuracin interna para un SGBD relacional.

Institut Poblenou

Gins Plazas

En la nocin de relacin es conveniente definir dos conceptos: INTENSIN o esquema de la relacin: es un conjunto de n pares de atributo dominio donde n es el grado del esquema de relacin. La intensin se corresponde con la cabecera cuando la relacin se percibe como una tabla. (Seran los atributos con su dominio en la tabla anterior). Los esquemas de las relaciones consisten en una lista de los atributos y de sus dominios correspondientes. EXTENSIN u ocurrencia (instancia): es un conjunto de m tuplas donde m es la cardinalidad. Cada tupla es un conjunto de n pares atributo-valor {(Ai; Vi)}. Donde Vi es el valor del dominio Di asociado al atributo Ai. {(Ai; Vi)} Di i significa el nmero de la fila. Cuando la relacin se representa como una tabla el cuerpo de sta corresponde a la extensin. Ejemplo 1: Intensin o esquema de la Relacin PERSONA: PERSONA={(dni:entero), (nombre:cadena), (direccion:cadena)} (es decir, el listado (como conjunto) de atributos con sus respectivos dominios) Extensin u ocurrencias de la Relacin PERSONA:

(es decir, el listado (como conjunto) de las tuplas (registros), poniendo para cada registro la pareja del nombre del atributo y su valor.) Ejemplo 2: La relacin OFICINA tiene la siguiente cabecera: (o intensin) { (Onum:NUM_OFICINA), (Calle:NOM_CALLE), (Area:NOM_AREA),
(Poblacin:NOM_POBLACION), (Telfono:NUM_TEL_FAX), (Fax:NUM_TEL_FAX)}.

Siendo la siguiente una de sus tuplas: (uno de los elementos de la extension, del cuerpo): { (Onum:O5), (Calle:Enmedio,8), (Area:Centro), (Poblacin:Castelln), (Telfono:964 201 240), (Fax:964 201 340)}.

Institut Poblenou

Gins Plazas

CLAVES:
Superclave:
Definicin 1:

Una superclave de una relacin de esquema R(a1, a2, ..., an) es un conjunto de uno o ms atributos que, tomados conjuntamente, permiten identificar de forma unvoca una entidad del conjunto de entidades.
Definicin 2:

Una superclave de una relacin de esquema R(a1, a2, ..., an) es un subconjunto de los atributos del esquema tal que no puede haber dos tuplas en la extensin de la relacin que tengan la misma combinacin de valores para los atributos del subconjunto.
Ejemplo: Consideremos la relacin EMPLOYEES (employee_id, DNI, first_name, last_name, email, phone_number, hire_date,
salary, commission_pct)

1) (employee_id) es suficiente para distinguir una instancia de empleado de las dems (el hecho de que tengan el employee_id diferente implica que SON empleados diferentes), por tanto es una superclave. 2) Adems, (employee_id, first_name) conjuntamente, tambin es superclave del conjunto de instancias de empleados. 3) Observamos que cualquier conjunto de atributos que contenga a employee_id ser una superclave tambin 4) (email): el email debe ser nico para cada persona (no puede haber dos mails iguales para diferentes personas). Si suponemos que en nuestra empresa TODOS los empleados tendrn asignado un mail, entonces s que sera una superclave. (PERO si no fuera obligatorio que todos los empleados tengan un email, en ese caso NO podra ser una superclave, porque 2 empleados con un valor de null en su mail seran indistinguibles). 5) El conjunto de atributos: (first_name, last_name, phone_number, hire_date, salary), es una superclave?

Institut Poblenou

Gins Plazas

Hemos de pensar: dada una combinacin de valores (datos) para dichos atributos, podr sealar a UNA nica instancia?. Si la respuesta es s, entonces es una superclave. Si no, entonces no lo es. O dicho de otra forma: Podra tener para 2 instancias diferentes (dos empleados diferentes) los MISMOS valores para todos esos atributos? Si eso puede pasar, es que NO es superclave (no me sirve para distinguirlos). Si no puede pasar, entonces s que es una superclave. En nuestro caso, hemos de pensar si es posible que 2 empleados diferentes puedan llamarse igual, ser contratados el mismo da, tener asociado el mismo nmero de telfono en la empresa (estn en la misma zona), y cobren lo mismo. Es muy difcil que eso ocurra, pero el hecho de que PUEDA ocurrir, hace que ese conjunto de atributos NO PUEDA SER Superclave. La superclave debe GARANTIZAR que eso no pueda ocurrir nunca, sean cuales sean sus valores. 6) (first_name) NO es superclave, pues puede haber varios empleados con el mismo nombre (y son empleados diferentes!!) 7) (first_name, last_name) NO es superclave, pues puede haber varios empleados con el mismo nombre y apellidos (y son empleados diferentes!!) 8) (employee_id, dni, email) es superclave. Tambien lo era cada uno de ellos por separado, y cualquier pareja de ellos. De los ejemplos anteriores podemos observar que las superclaves pueden contener atributos innecesarios: si C es superclave (C es un conjunto de atributos) entonces tambien lo es cualquier superconjunto de C (C y ms atributos) . Observacin: debido a que en el modelo relacional, no puede haber tuplas repetidas, el conjunto de todos los atributos de una relacin siempre formarn una superclave.

Claves Candidatas:

son las superclaves para las que ningn subconjunto propio es superclave. Es decir son superclaves mnimas. (subconjunto propio: subconjunto con menos elementos) (es decir, quitando los atributos innecesarios, o que sobran)
Una clave candidata se denomina simple si consta de UN NICO atributo Una clave candidata se denomina compuesta si consta de MS de UN atributo. Ejemplo: Consideremos la relacin EMPLOYEES (employee_id, DNI, first_name, last_name, email, phone_number, hire_date,
salary, commission_pct)

1) (employee_id, last_name) NO es clave candidata, pues employee_id ya es superclave

Institut Poblenou

Gins Plazas

Otro ejemplo: 2) supongamos que (nombre_cliente, calle_cliente) juntas, son suficientes para identificar a cada cliente (imagina que los clientes son EMPRESAS: 2 empresas que se llamen igual, y estn en la misma calle ... no parece posible). Sera una clave candidata (al igual que id_cliente), pues ninguno de los 2 atributos por separado es superclave.

Clave Primaria (PK: Primary Key): Es la clave candidata elegida por el

diseador de la BBDD para identificar a cada instancia de la entidad. La PK se debe escoger de forma que sus atributos nunca o muy raramente cambien.

Clave Alternativa: son el resto de claves candidatas no escogidas como

primaria

Ejemplo: Tenemos la relacin ENVOS (de los productos de los proveedores (ver diagrama anterior) con los siguientes atributos: ENVIOS (#S, #P, cantidad) #S:codigo del suministrador #P:codigo_pieza cantidad: cantidad de piezas enviadas Es Es Es Es Es Es (#S, #P, cantidad) una superclave? S (#S, cantidad) una superclave? No (#P, cantidad) una superclave? No (#S, #P) una superclave? S (#S) una superclave? No (#P) una superclave? No

Es (#S, #P, cantidad) una clave candidata? No, porque existe un subconjunto propio que ya es superclave: (#S, #P) Es (#S, #P) una clave candidata? S, porque es una superclave, y ninguno de sus subconjuntos propios es a su vez superclave. Es decir, es una superclave mnima. Adems, es la nica clave candidata en este caso, por lo tanto es la nica que podemos elegir como PK. Y observamos que es compuesta.

Institut Poblenou

Gins Plazas

Clave Ajena (FK: Foreign Key): es un conjunto de atributos de una relacin (R2), que forman una Clave Primaria de OTRA relacin (R1). Las claves ajenas representan relaciones entre datos. Son el mecanismo para expresar vnculos (interrelacin, asociacin) entre relaciones (tablas) a modo de referencia. Cabe destacar que la clave ajena y la correspondiente clave primaria han de estar definidas sobre los mismos dominios, aunque el nombre de los atributos no tiene por qu coincidir en ambas relaciones (tablas) Ejemplo:

Observad que, en este caso, (edificiodesp, nmerodesp) es una FK compuesta, y adems el nombre de sus atributos no coincide con la PK de la tabla a la que referencia. Ejemplo de atributo que forma parte de la clave primaria y de una clave fornea: Puede suceder que algn atributo de una relacin forme parte tanto de la clave primaria como de una clave fornea de la relacin. Esto se da en las relaciones siguientes: EDIFICIOS(nombreedificio, direccin), y DESPACHOS(edificio, nmero, superficie), donde {edificio} es una clave fornea que referencia EDIFICIOS. En este ejemplo, el atributo edificio forma parte tanto de la clave primaria como de la clave fornea de la relacin DESPACHOS.

Diagramas referenciales: codcli FACTURAS ----------> CLIENTES La clave ajena codcli de la tabla FACTURAS hace referencia a la clave primaria de la tabla CLIENTES: cliente al que corresponde la factura

Institut Poblenou

Gins Plazas

10

Institut Poblenou

Gins Plazas

3. REGLAS DE INTEGRIDAD (DEL MODELO RELACIONAL)

Denominamos integridad la propiedad de los datos de corresponder a representaciones plausibles del mundo real. Integridad de IDENTIDAD: Ninguno de los atributos que componen la clave primaria puede ser nulo. En una base de datos relacional nunca se almacena informacin de algo que no se puede identificar!!

Integridad REFERENCIAL: Si en una relacin hay alguna clave ajena, sus valores deben coincidir con valores de la clave primaria a la que hace referencia, o bien, deben ser nulos. Las claves forneas tienen por objetivo establecer una conexin con la clave primaria que referencian. Por lo tanto, los valores de una clave fornea deben estar presentes en la clave primaria correspondiente, o bien deben ser valores nulos. En caso contrario, la clave fornea representara una referencia o conexin incorrecta. La Base de Datos no debe contener Valores de Clave Ajena sin concordancia. Es decir, para cualquier valor no nulo de la clave ajena existe un valor asociado en la clave primaria de la relacin objetivo. (De una manera informal, diremos que no
puede haber hijos sin su padre) Profesor IMPARTE Asignatura

ASIGNATURA
Nombre Pepe Juan Dept 27 81 Telef 1111 3333 Nombre Mates Lengua Fisica Horas 5 3 8

PROFESOR

IMPARTE
Profesor Asignatura Pepe Mates Pepe Lengua Juan Mates Juan Fisica Manolo Naturales No existen esos valores en la PK a la que hace referencia en la tabla padre!! Viola la Integridad Referencial!

Integridad de DOMINIOS: El modelo relacional incluye, implcitamente, restricciones de dominios: al definir cada atributo sobre un dominio, se impone una restriccin sobre el conjunto de valores permitidos para cada atributo.

11

Institut Poblenou

Gins Plazas

Restauracin de la Integridad referencial

La regla de integridad referencial nos dice lo qu es un estado ilegal en la BBDD pero no nos dice cmo podemos evitarlo!! Qu hacer si estando en un estado legal, llega una operacin(*) que conduce a un estado ilegal? Existen dos opciones: Rechazar la operacin. Aceptar la operacin y realizar operaciones adicionales compensatorias que conduzcan a un estado legal. (*) Me refiero a una OPERACION de borrado (DELETE) o modificacin (UPDATE) de la tupla de una clave primaria referenciada por la clave ajena (violara la integridad referencial) Es tarea del diseador de la base de datos indicar qu operaciones se deben rechazar y cuales requieren operaciones adicionales, u operaciones de compensacin.

12

Institut Poblenou

Gins Plazas

Imaginad que se borra el Cliente 00321 (Ferran) de la tabla de CLIENTES, o si modifico su codcli: qu debe pasar con sus facturas de la tabla FACTURAS?
Regla de los nulos: Tiene sentido que la clave ajena acepte nulos? Regla de borrado: Qu hacer si se intenta borrar la tupla a la que hace referencia una clave ajena? Restringir Propagar Anular Regla de modificacin: Qu hacer si se intenta modificar el valor de la clave primaria de la tupla a la que hace referencia una clave ajena? Restringir Propagar Anular Entendiendo por: Restringir (RESTRICT, NO ACTION): rechazar la operacion de borrado o modificacion. Propagar (CASCADE): propagar la modificacion o borrado a la tabla sta (lo que se haga en la tabla principal (la que tiene la PK), se propaga a la que tiene la FK (en la que defino esta regla!)) Anular (ANULAR, SET NULL): (no que anule la accion y no la permita (en la tabla original)), sino que la permita, y le ponga NULOS en el atributo de la FK (o tambien est la SET DEFAULT , si lo que quiero es que me ponga otra cosa en la FK cuando modifique la tabla original (a la que hace referencia))

13

Institut Poblenou

Gins Plazas

Tened en cuenta, que la regla de integridad se coloca en la tabla que tiene la FK, y se aplica sobre dicha FK cuando el registro al que apunta (del padre) es afectado (por un borrado o modificacin) De una manera informal, podemos decir: ON DELETE mi padre, qu se hace conmigo? ( propagar? anular? prohibir?) ON UPDATE mi padre, qu ser de m? ( propagar? anular? prohibir?)

Al crear una tabla con la orden CREATE TABLE se pueden definir las reglas de integridad y las reglas para las claves ajenas. Ejemplos:

The ON DELETE CASCADE clause tells Oracle to delete the child tables when the corresponding parent table row is deleted. If the ON DELETE CASCADE clause is left off, Oracle will not allow the deletion of a parent row unless all the child rows are deleted first.
Oracle supports update restrict, delete restrict and delete cascade. It does not easily support: update cascade changes made to a parent key are cascaded to child update with null changes allowed to parent, child attribute changed to null delete with null parent deleted, child attribute changed to null

14

Institut Poblenou

Gins Plazas

4.

Esquema de una BBDD relacional

Para representar el esquema de una base de datos relacional se debe dar el nombre de las relaciones, los atributos de las relaciones, sus clave primaria, y las claves ajenas. En el esquema los nombres de la relaciones aparecen seguidos de los nombres de los atributos encerrados entre parntesis, las claves primarias son los atributos subrayados y las claves ajenas se representan mediante un diagrama referencial.

BD de una empresa inmobiliaria. Oficina (Onum, Calle, rea, Poblacin, Telfono, Fax) Plantilla (Enum, Nombre, Apellidos, Direccin, Telfono, Puesto, Fecha_nacimiento, Salario, DNI, Onum) Inmueble (Inum, Calle rea, Poblacin, Tipo, Habitaciones, Alquiler, Pnum, Enum, Onum) Inquilino (Qnum, Nombre, Apellidos, Direccin, Telfono, Alquiler_max) Propietario (Pnum, Nombre, Apellidos, Direccin, Telfono) Visita (Qnum, Inum, Fecha, Comentario) Diagrama referencial de claves ajenas Plantilla Onum Oficina: Oficina a la que pertenece el empleado Inmueble
Pnum

Propietario: Propietario del inmueble

Inmueble Enum Plantilla: Empleado encargado del inmueble Inmueble Onum Oficina: Oficina a la que pertenece el inmueble Visita Qnum Inquilino: Inquilino que ha visitado el inmueble Visita Inum Inmueble: Inmueble que ha sido visitado

El esquema de la base de datos, junto con las dependencias de la clave primaria y externa, se pueden mostrar grficamente mediante diagramas de esquema.

15

Institut Poblenou

Gins Plazas

Esquema Relacional de la BBDD de Pueblos:

Esquema Relacional de la BBDD de Employees:

16

Institut Poblenou

Gins Plazas

Esquema Relacional de la BBDD de Animal Mountain:

17