Tema 3 Modelo relacional

Contenido: Bases de Datos y Sistemas de Información Ing. Informática GRUPO A Tema 3 Modelo relacional 3.1 Terminología del modelo relacional 3.2 Paso del modelo ER al modelo relacional 3.3 Creación de tablas en el modelo relacional (SQL) 3.1 Terminología del modelo relacional Modelo Relacional Modelos de bases de datos Creado por Codd a Principios de los 70 Modelo lógico de datos de no muy alto nivel, orientado a registro. Sólida base teórica. Implementado en muchos SGBD. El concepto principal es la relación 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 básicos: Entidad: Igual que en el esquema ER. También se les llama tuplas o filas de la relación. Atributo: Igual que en el esquema ER. También se le llaman columnas de la relación. El dominio de los atributos tiene que ser simple: no se admiten atributos multivalorados ni compuestos. Esquema de una relación: viene dado por el nombre de la relación y una lista de atributos. Es el tipo de entidad. Conjunto de entidades: Relación o tabla. Ej: alumnos(dni, NombreYApellidos, domicilio, teléfono, cou ) Obs.: El orden de los atributos en la lista no importa. Lo fijamos porque nos viene bien para representarlo como tabla, pero cualquier permutación es válida. Instancia de una relación: Conjuntos de entidades. Cada entidad se representa como una tupla. Cada componente de la tupla corresponde con el valor del atributo correspondiente, según el orden enunciado en el esquema de la relación. Ej: Instancia de la relación alumnos: { (01234567Z, Manuel Vázquez Prieto, Calle del Jazmín 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. Representación: En el modelo relacional no se representan diagramas del esquema de la BD. Se pueden representar instancias de una relación de la siguiente forma: 1

Ej.: Instancia de la relación alumnos DNI NombreyApellidos Domicilio Teléfono COU 01234567Z Manuel Vázquez Prieto Calle del Jazmín 7 4 Izq 91-12345678 SI 3.2 Paso del modelo ER al modelo relacional Al traspasar información de ER al modelo relacional se pierde información (participación). En cambio, algunos requisitos que no podían representarse en el modelo ER sí van a poder indicarse aquí. 3.2.1. Definición de tablas Tipos de entidades Para cada tipo de entidad que no sea débil se crea una relación 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 secretaría los tipos de entidades dan lugar a las relaciones: Alumnos(DNI, Apellidos y Nombre, Domicilio, teléfono, COU) Asignaturas(Código, título, núm créditos) Profesores(DNI, Apellidos y nombre, Domicilio, teléfono) Aulas(Edificio, núm.edificio) Tipos de relaciones Para cada tipo de relación R se crea una relación con atributos: Por cada tipo de entidad que participa en la relación, los atributos de la clave primaria. Los atributos de la propia relación. Nota: En ocasiones hay que renombrar atributos para evitar tener varios con el mismo nombre. Ej: En el caso de la BD de secretaría los tipos de relación dan lugar a las relaciones: Matrícula(DNI, Código, Nota) Supervisa(DNI,DNI) Imparte(DNI, Código, Edificio, NumAula) Tipos de entidades débiles - El tipo de entidad débil E se transforma en una relación que incluye los atributos del tipo de relación más 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 relación con el doble rombo, si es binaria, no aporta nada y se podrá eliminar. Si tiene atributos, se pasan a la relación del tipo de entidad débil. Ej: Traspasar el siguiente diagrama entidad-relación a modelo relacional: 2

compositores DNI NombreyApe Autor canciones en CD s título duración Núm.serie títulocd intérprete Solución: compositores(dni, NombreYApe) canciones(titulo, duracion,númserie) autor(dni, titulo, duración, NúmSerie) en(titulo, duración, NúmSerie) <- Se debe eliminar CDs(Num.Serie, títulocd, intérprete) Generalizaciones Se tratan igual que en el caso de las entidades débiles. La relación IsA no se transforma en relación DNI Apellidos y Nombre Domicilio Teléfono personas is a COU alumnos profesores personas(dni, ApellidosyNombre, Domicilio, teléfono). alumnos(dni, COU) profesores(dni) 3.2.2 Claves Hay dos casos: 1. La relación proviene de un tipo de entidad en el esquema ER. La clave es la clave del tipo de entidad 2. La relación proviene de un tipo de relación en el esquema ER. Relaciones binarias: R relación binaria entre E1 y E2. R relación construida a partir de R Clave de E1 : c1 Clave de E2 : c2 3

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 relación proviene de un tipo de relación R entre tipos de entidad E1, E2,..., Ek. - Si todos participan con cardinalidad varios en R, entonces una superclave es la unión 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 relación adicionales y no hay otros requerimientos, la Def.: anterior nos proporciona una clave del tipo de relación. Ej: BD secretaría Alumnos(DNI, Apellidos y Nombre, Domicilio, teléfono, COU) Asignaturas(Código, título, núm.créditos) Otra clave candidata: { título } Profesores(DNI, Apellidos y nombre, Domicilio, teléfono) Aulas(Edificio, núm.edificio) Matricula(DNI, Código, Nota) Supervisa(DNISupervisor,DNISupervisado) Imparte(DNI, Codigo, Edificio,NumAula) Ej: BD de canciones: compositores(dni, NombreYApe) canciones(título, duración, NúmSerie) autor(dni, título, duración, NúmSerie) CDs(Núm.Serie, títulocd, intérprete) 4

3.2.3 Cuestiones de diseño En ocasiones es posible combinar 2 o más tablas en una sola: Ej: Nombre Apell. Personas Nacida Países DNI Esquema de la BD: Personas(DNI, Apell.) Países(Nombre) Nacida(DNI, Nombre) Nuevo Esquema: Personas(DNI,Apell, PaisNac) Países(Nombre) Ej: Esquema de BD: personas(dni, ApellidosyNombre, Domicilio, teléfono). alumnos(dni, COU) profesores(dni) Esquema modificado: personas(dni, ApellidosyNombre, Domicilio, teléfono,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 válida de la BD. 3.3 Creación de tablas en el modelo relacional. Objetivo: Representar por medio de tablas relacionales en SQL la información 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 automática. 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 creación/modificación/borrado de tablas en SQL CREATE TABLE nombredetabla(atributo1 tipo1,, atributon tipon CREATE TABLE empleados (nombre VARCHAR(20), apellidos VARCHAR(20), fechanacimiento DATE, edad INT 5

Observación: Las instrucciones SQL no distinguen entre mayúsculas y minúsculas Borrar una tabla: drop table nombredetabla; Modificar una tabla: - Añadir 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 programación habitualmente como atributo. En MySQL: - Numéricos: 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 número total de dígitos, d el número total de decimales), Además todos los tipos excepto bit y bool admiten la palabra clave unsigned como prefijo. Create table personal(., edad unsigned tinyint,.) - Cadenas de caracteres: Char(n) (n el número de caracteres), Varchar(n) (n el número 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 físico: char siempre lo mismo, varchar dependiendo de la longitud concreta del valor almacenado. Se prefiere varchar excepto si el tiempo de acceso es crítico en cuyo caso se elige char. - Fechas y horas: Date, Time, DateTime, TimeStamp (tiempo desde el 1 de enero de 1970) y YEAR (sólo el año). - Otros tipos: ENUM('value1','value2',...), SET('value1','value2',...). Además otros SQL como ORACLE y PostgreSQL permiten la creación de nuevos dominios como en este ejemplo: CREATE DOMAIN onoff AS VARCHAR CHECK VALUE IN ('on', 'off') Sin embargo esto no es válido en MySQL. Por el contrario los tipos MySQL enum y set no son admitidos por la mayor parte de los sistemas basados en SQL. 6

3.3.3 Añadiendo 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 vacíos create table persona (DNI varchar(10) not null, - Claves primarias: Se crean añadiendo una restricción Primary key(atrib1,,atribn), donde (atrib1,,atribn) son los atributos que forman la clave primaria: 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 estén declaradas not null. La mayoría de los sistemas fuerzan la restricción not null automáticamente sin exigir que se escriba de forma explícita. Sin embargo se recomienda indicarlo explícitamente 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 declaración del atributo que forma la clave. CREATE TABLE personal ( DNI varchar(10) not null primary key, apellidos VARCHAR(60) not null, domicilio varchar(80) 7

- Claves candidatas : Se transforman en restricciones UNIQUE. 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 válida en MySQL / SQL Server / Oracle / Access El nombre de la restricción (unalocporcm) es útil para referirse posteriormente a ella. Por ejemplo para eliminar la restricción 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 más 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 relación serán claves ajenas con respecto a la tabla correspondiente. Se representan con la sintaxis donde: FOREIGN KEY (atr1,,atrn) REFERENCES t(atr1,,atm ) - (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. Personas Nacida R País 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 8

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 países. Son sus tuplas padre (o madre). Qué ocurriría si borrásemos una tupla padre dejando su correspondiente tupla en Nacida? que se incumpliría la restricción! Por el ellos SGBD no nos va a permitir dejar tuplas huérfanas : 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 - Después borrar la tupla padre. La situación es similar en el caso de la modificación de una tupla padre, el SGBD no lo permite para no dejar tuplas huérfanas. Pero lo que hay que hacer para lograr la modificación es aún más complejo, no basta con modificar primero las tuplas hijas. Veamos un ejemplo: En países tenemos un país llamado Crujidistan. Hemos metido ya varios nacidos en ese país en Nacida, es decir la tupla para Crujidistan tiene varias tuplas hijas. Sin embargo comprobamos que el nombre del país es Krujidistan. Como hemos dicho no podemos cambiarlo sin más, entonces: - Primero añadimos una nueva tupla en países con nombre Krujidistan - Ahora modificamos los nombres de país 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 añaden como sufijos a la declaración de la restricción foreign key correspondiente son: - ON DELETE CASCADE: Al borrar una tupla padre borrar automáticamente 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 tomarán el valor que sigue a default. Las mismas 3 opciones existen cambiando ON DELETE por ON UPDATE. Además se pueden combinar ambas posibilidades. CREATE TABLE Nacida( nombrepersona varchar(10) not null, 9

apellidospersona varchar(100) not null, nombrepais varchar(50) not null DEFAULT apátrida, 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 Atención: estas posibilidades son muy potentes, pero deben usarse con cuidado y documentarse adecuadamente. Hay que tener en cuenta que la creación de claves ajenas también afecta a la hora de borrar tablas completas con DROP Table: se deben borrar primero las tablas que contienen referencias externas: 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 (sólo de esta última forma si la propiedad implica a más de una columna). 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 generación del esquema. - Un buen diseño de esquema de bases de datos, sin información redundante y con restricciones de integridad debidamente fijadas nos asegura una BD coherente y fácil de mantener. - Para las restricciones de integridad que no pueden asegurarse con los mecanismos anteriores existen en algunos SGBD como Oracle aún otros mecanismos más complejos, como los trigger, que veremos más adelante. 10