Bases de Datos y Sistemas de Informacin Ing.

Informtica GRUPO A

Tema 3 Modelo relacional

Contenido:

3.1 Terminologa del modelo relacional 3.2 Paso del modelo ER al modelo relacional 3.3 Creacin de tablas en el modelo relacional (SQL)

3.1 Terminologa del modelo relacional

Modelo Relacional Modelos de bases de datos Creado por Codd a Principios de los 70 Modelo lgico de datos de no muy alto nivel, orientado a registro. Slida base terica. Implementado en muchos SGBD. El concepto principal es la relacin o tabla . OJO: No hay que confundir la tabla con las relaciones del modelo ER. Aqu las relaciones valen para tipos de relaciones igual que para tipos de entidades. Algunos conceptos bsicos: Entidad: Igual que en el esquema ER. Tambin se les llama tuplas o filas de la relacin. Atributo: Igual que en el esquema ER. Tambin se le llaman columnas de la relacin. El dominio de los atributos tiene que ser simple: no se admiten atributos multivalorados ni compuestos. Esquema de una relacin: viene dado por el nombre de la relacin y una lista de atributos. Es el tipo de entidad. Conjunto de entidades: Relacin o tabla.

Ej: alumnos(DNI, NombreYApellidos, domicilio, telfono, cou ) Obs.: El orden de los atributos en la lista no importa. Lo fijamos porque nos viene bien para representarlo como tabla, pero cualquier permutacin es vlida. Instancia de una relacin: Conjuntos de entidades. Cada entidad se representa como una tupla. Cada componente de la tupla corresponde con el valor del atributo correspondiente, segn el orden enunciado en el esquema de la relacin. Ej: Instancia de la relacin alumnos: { (01234567Z, Manuel Vzquez Prieto, Calle del Jazmn 7 4 Izq, 91-12345678, COU = SI), ....} Obs.: Ahora hablamos siempre de conjuntos de entidades, nunca de multiconjuntos. Nota: En el modelo relacional no se distingue entre tipos de entidades y tipos de relaciones. Representacin: En el modelo relacional no se representan diagramas del esquema de la BD. Se pueden representar instancias de una relacin de la siguiente forma:

Ej.: Instancia de la relacin alumnos

DNI 01234567Z

NombreyApellidos Manuel Vzquez Prieto

Domicilio
Calle del Jazmn 7 4 Izq

Telfono 91-12345678

COU SI

3.2

Paso del modelo ER al modelo relacional

Al traspasar informacin de ER al modelo relacional se pierde informacin (participacin). En cambio, algunos requisitos que no podan representarse en el modelo ER s van a poder indicarse aqu.

3.2.1. Definicin de tablas

Tipos de entidades Para cada tipo de entidad que no sea dbil se crea una relacin con el mismo nombre y conjunto de atributos. Obs.: En este punto no se indica nada acerca de los tipos de relaciones en los que participa el tipo de entidades. Ej: En el caso de la BD de secretara los tipos de entidades dan lugar a las relaciones: Alumnos(DNI, Apellidos y Nombre, Domicilio, telfono, COU) Asignaturas(Cdigo, ttulo, nm crditos) Profesores(DNI, Apellidos y nombre, Domicilio, telfono) Aulas(Edificio, nm.Edificio) Tipos de relaciones Para cada tipo de relacin R se crea una relacin con atributos: Por cada tipo de entidad que participa en la relacin, los atributos de la clave primaria. Los atributos de la propia relacin. Nota: En ocasiones hay que renombrar atributos para evitar tener varios con el mismo nombre. Ej: En el caso de la BD de secretara los tipos de relacin dan lugar a las relaciones: Matrcula(DNI, Cdigo, Nota) Supervisa(DNI,DNI) Imparte(DNI, Cdigo, Edificio, NumAula) Tipos de entidades dbiles - El tipo de entidad dbil E se transforma en una relacin que incluye los atributos del tipo de relacin ms los atributos necesarios para la clave de E. - Los tipos de relaciones en los que participa E deben incluir todos los atributos de la clave de E. Obs.: - El tipo de relacin con el doble rombo, si es binaria, no aporta nada y se podr eliminar. Si tiene atributos, se pasan a la relacin del tipo de entidad dbil. Ej: Traspasar el siguiente diagrama entidad-relacin a modelo relacional:

compositores

DNI NombreyApe

Autor

canciones

en

CDs

ttulo

duracin

Nm.serie

ttuloCD

intrprete

Solucin: compositores(DNI, NombreYApe) canciones(titulo, duracion,NmSerie) autor(DNI, titulo, duracin, NmSerie) en(titulo, duracin, NmSerie) <- Se debe eliminar CDs(Num.Serie, ttuloCD, intrprete) Generalizaciones Se tratan igual que en el caso de las entidades dbiles. La relacin IsA no se transforma en relacin
DNI Apellidos y Nombre Domicilio Telfono

personas

is a COU alumnos profesores

personas(DNI, ApellidosyNombre, Domicilio, telfono). alumnos(DNI, COU) profesores(DNI) 3.2.2 Claves Hay dos casos: 1. La relacin proviene de un tipo de entidad en el esquema ER. La clave es la clave del tipo de entidad 2. La relacin proviene de un tipo de relacin en el esquema ER. Relaciones binarias: R relacin binaria entre E1 y E2. R relacin construida a partir de R Clave de E1 : c1 Clave de E2 : c2

Atributos de R: Atributos de E1 + Atributos de E2 + Atributos de R a) Una a una

E1 R E2

Dos superclaves: c1 y c2 b) Una a varias

E1 R E2

Superclave: c2 c) Varias a varias

E1 R E2

Superclave : c1 c2 Relaciones n-arias Supongamos que la relacin proviene de un tipo de relacin R entre tipos de entidad E1, E2, ..., Ek. - Si todos participan con cardinalidad varios en R, entonces una superclave es la unin de las claves de E1, E2, ..., Ek. - Si algunos tipos de entidad participan con cardinalidad una en R, entonces uno de ellos puede ser excluido de la superclave. Obs.: - Si los tipos de entidades E1, E2,...,Ek no intervienen en tipos de relacin adicionales y no hay otros requerimientos, la Def.: anterior nos proporciona una clave del tipo de relacin. Ej: BD secretara Alumnos(DNI, Apellidos y Nombre, Domicilio, telfono, COU) Asignaturas(Cdigo, ttulo, nm.crditos) Otra clave candidata: { ttulo } Profesores(DNI, Apellidos y nombre, Domicilio, telfono) Aulas(Edificio, nm.Edificio) Matricula(DNI, Cdigo, Nota) Supervisa(DNISupervisor,DNISupervisado) Imparte(DNI, Codigo, Edificio,NumAula) Ej: BD de canciones: compositores(DNI, NombreYApe) canciones(ttulo, duracin, NmSerie) autor(DNI, ttulo, duracin, NmSerie) CDs(Nm.Serie, ttuloCD, intrprete)

3.2.3

Cuestiones de diseo

En ocasiones es posible combinar 2 o ms tablas en una sola: Ej:

Nombre Apell. DNI Personas Nacida Pases

Esquema de la BD: Personas(DNI, Apell.) Pases(Nombre) Nacida(DNI, Nombre) Nuevo Esquema: Personas(DNI,Apell, PaisNac) Pases(Nombre) Ej: Esquema de BD: personas(DNI, ApellidosyNombre, Domicilio, telfono). alumnos(DNI, COU) profesores(DNI) Esquema modificado: personas(DNI, ApellidosyNombre, Domicilio, telfono,AlumnOProfe, COU). Obs.: - Se admite la existencia de una valor nulo (NULL) en todo dominio de un atributo. - Los atributos que forman parte de una clave no pueden tomar el valor nulo en ninguna instancia vlida de la BD.

3.3 Creacin de tablas en el modelo relacional. Objetivo: Representar por medio de tablas relacionales en SQL la informacin representada en un diagrama ER y sus restricciones asociadas de forma que el SGBD verifique las restricciones de integridad que garantizan la coherencia de la base de datos de forma automtica. Nota: Aunque las instrucciones que se describen en este apartado existen con una u otra variante en todos los sistemas SQL utilizaremos la sintaxis de MySQL para aspectos particulares, aunque mencionaremos otros sistemas como ORACLE. 3.3.1 Sintaxis simplificada para la creacin/modificacin/borrado de tablas en SQL CREATE TABLE nombreDeTabla(atributo1 tipo1, , atributon tipon);
Ejemplo: CREATE TABLE empleados (nombre VARCHAR(20), apellidos VARCHAR(20), fechaNacimiento DATE, edad INT );

Observacin: Las instrucciones SQL no distinguen entre maysculas y minsculas Borrar una tabla: drop table nombreDeTabla; Modificar una tabla: - Aadir atributos: alter table r add A D - Eliminar atributos: alter table r drop A r : nombre de la tabla, A: nombre del atributo, D: tipo (dominio) del atributo. 3.3.2 Tipos o dominios de atributos

Se llama dominio de un atributo al rango de valores que puede tomar inicialmente (sin considerar otras restricciones), valor que se conoce en programacin habitualmente como atributo. En MySQL: - Numricos: bit (0,1), tinyint (-128,127), bool o Boolean (true=1, false=0), smallint (-32768 to 32767), mediumint (-8388608 to 8388607), int (-2147483648 to 2147483647), bigint (9223372036854775808 to 9223372036854775807), float, Decimal(m,d) (m el nmero total de dgitos, d el nmero total de decimales), Adems todos los tipos excepto bit y bool admiten la palabra clave unsigned como prefijo. Ejemplo: Create table personal(. , edad unsigned tinyint,.) - Cadenas de caracteres: Char(n) (n el nmero de caracteres), Varchar(n) (n el nmero de caracteres) y Text (cadena sin limite de caracteres) Create table cuento( nombreAutor varchar(20), titulo varchar(50), elCuento text); La diferencia entre varchar y char es lo que ocupan en el almacenamiento fsico: char siempre lo mismo, varchar dependiendo de la longitud concreta del valor almacenado. Se prefiere varchar excepto si el tiempo de acceso es crtico en cuyo caso se elige char. - Fechas y horas: Date, Time, DateTime, TimeStamp (tiempo desde el 1 de enero de 1970) y YEAR (slo el ao). - Otros tipos: ENUM('value1','value2',...), SET('value1','value2',...). Adems otros SQL como ORACLE y PostgreSQL permiten la creacin de nuevos dominios como en este ejemplo:
CREATE DOMAIN onoff AS VARCHAR CHECK VALUE IN ('on', 'off')

Sin embargo esto no es vlido en MySQL. Por el contrario los tipos MySQL enum y set no son admitidos por la mayor parte de los sistemas basados en SQL.

3.3.3

Aadiendo restricciones de integridad

- Default: Permite dar valores por defecto a alguna(s) columnas mediante la palabra clave DEFAULT:
CREATE TABLE PolizaSeguros ( DNI varchar(10), NombreYApellidos varchar(255), TipoPoliza varchar(20) DEFAULT 'Seguro Vida' );

Se pueden usar funciones del sistema. Por ejemplo si getDate() devuelve la fecha actual:
CREATE TABLE PolizaSeguros ( DNI varchar(10), NombreYApellidos varchar(255), TipoPoliza varchar(20)DEFAULT 'Seguro Vida', Fecha DATE DEFAULT getDate() );

- Not null: indica que los valores de una columna no pueden estar vacos Ejemplo: create table persona (DNI varchar(10) not null, ); - Claves primarias: Se crean aadiendo una restriccin Primary key(atrib1,,atribn), donde (atrib1,,atribn) son los atributos que forman la clave primaria: Ejemplo:
CREATE TABLE personal ( nombre varchar(20) not null, apellidos VARCHAR(60) not null, domicilio varchar(80), PRIMARY KEY (nombre, apellidos) );

Se requiere que todas las columnas que participan en la clave primaria estn declaradas not null. La mayora de los sistemas fuerzan la restriccin not null automticamente sin exigir que se escriba de forma explcita. Sin embargo se recomienda indicarlo explcitamente por claridad. En caso de que la clave primaria est formada por una nica columna se admite una sintaxis alternativa consistente en escribir las palabras Primary Key al final de la declaracin del atributo que forma la clave. Ejemplo:
CREATE TABLE personal ( DNI varchar(10) not null primary key, apellidos VARCHAR(60) not null, domicilio varchar(80) );

- Claves candidatas : Se transforman en restricciones UNIQUE. Ejemplo:

CREATE TABLE localidades ( Codigo int NOT NULL, nombre varchar(100) NOT NULL, comunidad varchar(100), poblacion int, primary key(codigo), CONSTRAINT unaLocporCM UNIQUE (nombre,comunidad) )

La sintaxis anterior es vlida en MySQL / SQL Server / Oracle / Access El nombre de la restriccin (unaLocporCM) es til para referirse posteriormente a ella. Por ejemplo para eliminar la restriccin de la tabla posteriormente: Oracle/Access/SQL server:
ALTER TABLE localidades DROP CONSTRAINT unaLocporCM

MySQL:
ALTER TABLE localidades DROP INDEX unaLocporCM

- Claves ajenas: obligan a que una o ms columnas de las tablas existan previamente en otra tabla. Se usa sobre todo al pasar al diagrama relacional relaciones de un diagrama ER: las claves prestadas por la relacin sern claves ajenas con respecto a la tabla correspondiente. Se representan con la sintaxis
FOREIGN KEY (atr1,,atrn) REFERENCES t(atr1,,atm)

donde: - (atr1,,atrn) son atributos de la tabla actual - (atr1,,atrn) son atributos que forman la clave primaria de la tabla t, que ya existe. - El dominio de los atributos (atr1,atr1),,(atrn,atrn) son compatibles. Ejemplo:

Personas

R Nacida

Pas

Se refleja en las tablas SQL como (nos inventamos los atributos, no vienen en el diagrama):
CREATE TABLE personas ( nombre varchar(10) not null, apellidos varchar(100) not null, direccion varchar(200), edad int, primary key(nombre,apellidos) ); CREATE TABLE Paises( Nombre varchar(50) not null primary key, Poblacion int

); CREATE TABLE Nacida( nombrePersona varchar(10) not null, apellidosPersona varchar(100) not null, nombrePais varchar(50) not null, fecha DATE, primary key(nombrePersona,apellidosPersona), foreign key(nombrePersona,apellidosPersona) references personas(nombre,apellidos), foreign key(nombrepais) references paises(nombre) );

Problema: ahora cada tupla/fila de Nacida (la llamaremos tupla hija) depende de una tupla en personas y otra en pases. Son sus tuplas padre (o madre). Qu ocurrira si borrsemos una tupla padre dejando su correspondiente tupla en Nacida? que se incumplira la restriccin! Por el ellos SGBD no nos va a permitir dejar tuplas hurfanas: si queremos borrar una tupla en Pais, por ejemplo, primero debemos borrar todas la tuplas hijas en Nacida. El esquema es: Primero borrar tuplas hijas Despus borrar la tupla padre.

La situacin es similar en el caso de la modificacin de una tupla padre, el SGBD no lo permite para no dejar tuplas hurfanas. Pero lo que hay que hacer para lograr la modificacin es an ms complejo, no basta con modificar primero las tuplas hijas. Veamos un ejemplo: En pases tenemos un pas llamado Crujidistan. Hemos metido ya varios nacidos en ese pas en Nacida, es decir la tupla para Crujidistan tiene varias tuplas hijas. Sin embargo comprobamos que el nombre del pas es Krujidistan. Como hemos dicho no podemos cambiarlo sin ms, entonces: - Primero aadimos una nueva tupla en pases con nombre Krujidistan - Ahora modificamos los nombres de pas de las tuplas hijas a Krujidistan. - Finalmente borramos la tupla para Crujidistan, que ya no tiene tuplas hijas. Los SGBD avanzados como Oracle disponen de medios para automatizar, si se desea este proceso. Al declarar la tabla que contendr tuplas hijas podemos decir qu deseamos que ocurra con ellas al borrar/modificar la tupla padre. Las posibilidades, que se aaden como sufijos a la declaracin de la restriccin foreign key correspondiente son: ON DELETE CASCADE: Al borrar una tupla padre borrar automticamente sus hijas ON DELETE SET NULL: Al borrar una tupla padre poner a null los campos del padre referenciados en sus hijas, si es posible. ON DELETE DEFAULT: Al borrar una tupla padre los campos del padre referenciados en sus hijas tomarn el valor que sigue a default.

Las mismas 3 opciones existen cambiando ON DELETE por ON UPDATE. Adems se pueden combinar ambas posibilidades. Ejemplo:
CREATE TABLE Nacida( nombrePersona varchar(10) not null,

apellidosPersona varchar(100) not null, nombrePais varchar(50) not null DEFAULT aptrida, fecha DATE, primary key(nombrePersona,apellidosPersona), foreign key(nombrePersona,apellidosPersona) references personas(nombre,apellidos) ON DELETE CASCADE ON UPDATE CASCADE, foreign key(nombrepais) references paises(nombre) ON DELETE DEFAULT ON UPDATE CASCADE );

Atencin: estas posibilidades son muy potentes, pero deben usarse con cuidado y documentarse adecuadamente. Hay que tener en cuenta que la creacin de claves ajenas tambin afecta a la hora de borrar tablas completas con DROP Table: se deben borrar primero las tablas que contienen referencias externas: Ejemplo: Drop table nacida; Drop table paises; Drop table personas; - check : Se aseguran de que los valores que se van a almacenar verifican cierta propiedad P. Sintaxis: check(P), donde P es la propiedad. Se puede poner al lado de la columna o al final (slo de esta ltima forma si la propiedad implica a ms de una columna). Ejemplo: Create table ventaAlcohol( DNI varchar(10) not null primary key, nombreyapellidos varchar(100), edad int, Check (edad>17) ); 3.3.4 Conclusiones Las restricciones expresadas en los requerimientos verbales iniciales deben quedar reflejadas en el esquema de base de datos final. No todas las restricciones quedan recogidas en el diagrama ER, as que deben apuntarse aparte y tenerse en cuenta en la generacin del esquema. Un buen diseo de esquema de bases de datos, sin informacin redundante y con restricciones de integridad debidamente fijadas nos asegura una BD coherente y fcil de mantener. Para las restricciones de integridad que no pueden asegurarse con los mecanismos anteriores existen en algunos SGBD como Oracle an otros mecanismos ms complejos, como los trigger, que veremos ms adelante.

10