Gbd02_tema 4. El Modelo Relacional

GBD -1º A.S.I.R.I.E.S. JULIAN MARIAS

CURSO 2011 - 2012 1

TEMA 4. EL MODELO RELACIONAL

1. CONCEPTOS FUNDAMENTALES DEL MODELO RELACIONAL

2. ELEMENTOS DEL MODELO RELACIONAL3. RESTRICCIONES4. LAS 12 REGLAS DE CODD.5. TRANSFORMACIÓN DEL MODELOR E/R AL

MODELO RELACIONAL6. NORMALIZACIÓN


CURSO 2011 - 2012 2

1. CONCEPTOS DEL MODELO RELACIONAL

E. F. Codd (IBM) fue el creador en los 70’s.Necesario ya que el modelo E/R no se puede aplicar a ningún SGBDEl modelo E/R se centra en reflejar la realidad, el modelo lógico o relacional se centra en adaptarlo a las limitaciones de los SGBD.Solo se puede implantar en aquellos SGBD que lo soporten.Mantiene la independencia de la estructura lógica de la BD respecto a la estructura física (modo de almacenamiento, etc..).


CURSO 2011 - 2012 3

Conceptos del ModeloRelacional

El modelo relacional intenta conseguir los siguientes objetivos:

Independencia física de los datosIndependencia lógica de los datos.- Cualquier cambio en los objetos de la BD no deben repercutir en los programas y usuarios que acceden a la misma.Flexibilidad.- Posibilidad de que los usuarios vean la información de la forma más adecuada.Uniformidad.- Solo se trabaja con tablas.Sencillez.- Las características anteriores junto con lenguajes sencillos, hacen que sea un modelo sencillo de comprender y utilizar por elusuario.


CURSO 2011 - 2012 4

2. ELEMENTOS DEL MODELO

Codd introdujo una def. Matemática de todos los elementos(no se ve)Tabla o Relación

Es una matriz con filas y columnas donde las filas reciben el nombre de tuplas (ocurrencias en el modelo E/R)y las columnas representan atributos y se pueden nombrar como campos de la tabla (atributos en el modelo E/R). Las filas representan registros. Tanto las entidades como las relaciones del modelo E/R se transforman a tablas


CURSO 2011 - 2012 5

Elementos del Modelo

TuplaCada una de las filas de la tabla, Idea clásica de registroDos reglas que deben cumplir las tuplas

Cada tupla debe corresponder con un elemento del mundo real.En una tabla no puede haber dos tuplas iguales (con todos los valores iguales)


CURSO 2011 - 2012 6


DominioMismo concepto que en el modelo E/RTodos los posibles valores que puede tomar un determinado campo de la tabla.Tienen que tener un nombre y un tipo de dato asociado.Los dominios pueden ser de dos tipos:

Generales.- Sus valores están comprendidos entre un max. y un minimo. Ej: Codigo postal formado por números naturales de 5 cifras del 00000 al 99999.Restringuidos.- Sus valores pertenecen a un cjto. De valores especifico. Ej: Sexo, toma el valor H o M,


CURSO 2011 - 2012 7


DominioEjemplos


CURSO 2011 - 2012 8


GradoNº de campos de la tabla

CardinalidadNº de tuplas de la tabla, Referencia un aspecto dinámico de la BD.


CURSO 2011 - 2012 9


ClavesEs el conjunto de columnas o campos que me permiten distinguir dentro de una tabla una tupla de otra. Esta se denomina clave primaria (primary key)Tipos de clave: Además de la clave primaria en una tabla pueden existir otro tipos de clave:

Clave candidata.- Cjto. de campos que identifican de forma unívoca a una tupla. De aqui sale la clave primaria.Clave alternativa.- Cualquier clave candidata que no sea primaria.Clave ajena (foreign key).- Cjto. de campos de una tabla que coinciden con la clave primaria de otra tabla. Ej: Jugador (Nºjugador, Nombre, NºEquipo), Nº equipo clave foranea.


CURSO 2011 - 2012 10


Propiedades de las TablasPara representar las tablas se utiliza la siguiente sintaxis:NombreTabla ( Campo1, Campo2, …., CampoN)

Donde Campo1, Campo2, .. son los nombres de los campos de la tablaEl/Los campo/s que forman parte de la clave primaria se identifican subrayandolos.

Cada tabla tiene que tener un nombre significativoCada campo de la tabla toma un solo valor en cada tupla(1FN)


CURSO 2011 - 2012 11


Propiedades de las Tablas (cont.)En una tabla no existen dos campos con el mismo nombre, en tablas distintas puede.El orden de los campos no importa (es aconsejable que la clave primaria sea el primero)El orden de las tuplas no importa.No hay tuplas duplicadas.


CURSO 2011 - 2012 12


Tipos de tablas. Clasificación en relación al tiempo de existencia

PERSISTENTES.- Solo pueden ser borradas por los usuariosBases.- Son las tablas de la BD, contienen tanto los datos como los metadatos (def. De tabla, campos, dominios, etc..)Vistas.- Tablas que se definen a partir de una consulta, también denominadas relaciones virtuales. Lo único que almacenan es la definición de la consulta. Una actualización de la tablas Bases, de las que depende, tiene reflejo inmediatamente en la vista.Instantáneas.- Son vistas que almacenan los datos que muestran, además de la consulta que dio lugar a esa vista. Una actualización de la tablas Bases de las que depende, no se reflejan inmediatamente en la vista.


CURSO 2011 - 2012 13


Tipos de tablas. Clasificación en relación al tiempo de existencia

TEMPORALES.- Se eliminan automáticamente por el sistema, suelen ser el resultado de una consulta, las utiliza el SGBD como almacen intermedio.

Ejemplo de tabla:


CURSO 2011 - 2012 14

3. RESTRICCIONES

Condiciones de obligado cumplimiento por las tuplas de una tabla.Tenemos las siguientes:Inherentes al modelo.- Prefijadas por el modelo:

No puede haber dos tuplas iguales.El orden de las tuplas no es significativoEl orden de los campos no es significativoCada atributo solo puede tomar un valor.


CURSO 2011 - 2012 15

Restricciones

Restricciones Semánticas. Restriccionespropias de los datos (def. por el admin.)

Clave Principal (primary key).- Marca uno o varios atributos como identificadores. Estos no pueden repetirse ni tomar valores nulos.Unicidad (unique).- Impide que los valores de los atributos marcados con esta restricción puedanrepetirse. Restricción obligatoria en claves alternativas: Empleado(Cod_Empleado, Dni,…)


CURSO 2011 - 2012 16

Restricciones

Restricciones Semánticas. (cont.)Obligatoriedad (not null).- Prohíbe que el atributo marcadode esta forma quede vacío (es decir impide que puedacontener el valor nulo, null).Integridad referencial(foreign key).- Sirve para indicar unaclave externa (foránea) sobre uno o más atributos. Los atributos marcados de esta forma sólo podrán contenervalores que estén relacionados con la clave principal de la tabla que relacionan (llamada tabla principal). Dichosatributos sí podrán contener valores nulos. Una clave foranea no podrá tener un valor distinto de los que tenga la clave principal con la que esta asociado.


CURSO 2011 - 2012 17

Restricciones

Integridad referencial(foreign key).- Ejemplo: Cliente y Alquileres


CURSO 2011 - 2012 18

Restricciones

Integridad referencial(foreign key).- Problemas en las operaciones de modificación y borrado. ¿Quésucede si eliminamos un cliente que estarelacionado en alquileres?. Para solucionarlo se utilizan las siguientes estrategias:

Prohibir la operación (no action)Transmitir la operación en cascada (cascade)Colocar nulos (set null)Usar un valor por defecto (default)


CURSO 2011 - 2012 19

Restricciones

Reglas de validación (check).- Condiciónlógica que debe de cumplir un dato concretopara darlo por válido. Por ejemplo restringir el campo sueldo para que siempre sea mayor de 1000, sería una regla de validación. Tambiénpor ejemplo que la fecha de inicio sea mayor que la fecha final.


CURSO 2011 - 2012 20

Restricciones

Ejemplo: De creación de tablas en OracleCREATE TABLE FABRICANTES(

CD_FAB NUMBER(3) NOT NULL DEFAULT 100, NOMBRE VARCHAR2(15) UNIQUE, PAIS VARCHAR2(15) CONSTRAINT CK_PA CHECK(PAIS=UPPER(PAIS)), CONSTRAINT PK_FA PRIMARY KEY (CD_FAB), CONSTRAINT CK_NO CHECK(NOMBRE=UPPER(NOMBRE)) );

CREATE TABLE ARTICULOS( ARTIC VARCHAR2(20) NOT NULL, COD_FA NUMBER(2) NOT NULL, PESO NUMBER(3) NOT NULL CONSTRAINT CK1_AR CHECK(PESO>0), CATEGORIA VARCHAR2(10) NOT NULL, PRECIO_VENTA NUMBER(4) CONSTRAINT CK2_AR CHECK(PRECIO_VENTA>0), PRECIO_COSTO NUMBER(4) CONSTRAINT CK3_AR CHECK(PRECIO_COSTO>0), EXISTENCIAS NUMBER(5), CONSTRAINT PK_ART PRIMARY KEY (ARTIC,COD_FA,PESO,CATEGORIA), CONSTRAINT FK_ARFA FOREIGN KEY (COD_FA) REFERENCES FABRICANTES

(CD_FAB) ON DELETE CASCADE, CONSTRAINT CK_CAT CHECK(CATEGORIA IN (‘Primera’,’Segunda’,’Tercera’)) );


CURSO 2011 - 2012 21

Restricciones

Aserciones (Assertion) Igual que CHECK pero puede afectar a 2 o más relaciones, portanto, la condición a cumplir se establecesobre campos de distintas relaciones. Puedenimplicar a subconsultas en la condición.


CURSO 2011 - 2012 22

Restricciones

Disparadores o triggers.- Se trata de pequeños programas grabados en la base de datos que se ejecutan automáticamente cuandose cumple una determinada condición. Sirvenpara realizar una serie de acciones cuandoocurre un determinado evento (cuando se añade una tupla, cuando se borra un dato, cuando un usuario abre una conexión…) Los triggers permiten realizar restriccionesmuy potentes; pero son las más difíciles de crear.


CURSO 2011 - 2012 23

Restricciones

Ejemplo: De Disparadores en Oracle. Cada vez que se realiza una operación de actualización o borrado se inserta en la tabla AUDITAEMPLE una fila quecontendrá varios campos: fecha y hora de la operación, número y apellido del empleado afectado, y la operación que se realiza.

CREATE OR REPLACE TRIGGER auditar_act_empBEFORE INSERT OR DELETE ON EMPLE FOR EACH ROW BEGIN IF DELETING THEN INSERT INTO AUDITAREMPLE VALUES (TO_CHAR(sysdate,’DD/MM/YY*HH24:MI*’) || :OLD.EMP_NO|| ‘*’ || :OLD.APELLIDO ||

‘*BORRADO’); ELSIF INSERTING THEN INSERT INTO AUDITAREMPLE VALUES (TO_CHAR(sysdate,’DD/MM/YY*HH24:MI*’) || :NEW.EMP_NO|| ‘*’ || :NEW.APELLIDO ||

‘*INSERCION’); END IF; END;


CURSO 2011 - 2012 24

4. LAS 12 REGLAS DE CODD

Preocupado por los productos que decían ser sistemas gestores de bases de datos relacionales (RDBMS) sin serlo, Codd publica las 12 reglas que debe cumplir todo DBMS para ser considerado relacional. Estas reglas en la práctica las cumplen pocos sistemas relacionales. Las reglas son:

(1) Información. Toda la información de la base de datos (metadatos) debe estar representada explícitamente en el esquema lógico. Es decir, todos los datos están en las tablas. (2) Acceso garantizado. Todo dato es accesible sabiendo el valor de su clave y el nombre de la columna o atributo que contiene el dato. (3) Tratamiento sistemático de los valores nulos. El DBMS debe permitir el tratamiento adecuado de estos valores. De ese modo el valor nulo se utiliza para representar la ausencia de información de un determinado registro en un atributo concreto.


CURSO 2011 - 2012 25

Las 12 Reglas de Codd

(4) Catálogo en línea basado en el modelo relacional. Los metadatos deben de ser accesibles usando un esquema relacional. Es decir la forma de acceder a los metadatos es la misma que la de acceder a los datos. (5) Sublenguaje de datos completo. Al menos debe de existir un lenguaje que permita el manejo completo de la base de datos. Este lenguaje, por lo tanto, debe permitir realizar cualquier operación sobre la misma.


CURSO 2011 - 2012 26


(6) Actualización de vistas. El SGBD debe encargarse de que las vistas muestren la última información. No son válidas vistas que muestren datos que no están al día. (7) Inserciones, modificaciones y eliminaciones de dato nivel. Cualquier operación de modificación debe actuar sobre conjuntos de filas o registros, nunca deben actuar registro a registro. (8) Independencia física. Los datos deben de ser accesibles desde la lógica de la base de datos aún cuando se modifique el almacenamiento. La forma de acceder a los datos no varía porque el esquema físico de la base de datos, cambie.


CURSO 2011 - 2012 27


(9) Independencia lógica. Los programas no deben verse afectados por cambios en las tablas. Que las tablas cambien no implica que cambien los programas. (10) Independencia de integridad. Las reglas de integridad deben almacenarse en la base de datos (en el diccionario de datos), no en los programas de aplicación. (11) Independencia de la distribución. El sublenguaje de datos debe permitir que sus instrucciones funciones igualmente en una base de datos distribuida que en una que no lo es. (12) No subversión. Si el SGBD posee un lenguaje procedimental que permita crear bucles de recorrido fila a fila, éste no puede utilizarse para incumplir o evitar las reglas relacionales anteriores. Especialmente la regla 7 no puede ser incumplida por ningún lenguaje del SGBD.


CURSO 2011 - 2012 28

5. TRANSFORMACIÓN DEL MODELO E/R AL MODELO

RELACIONALTransformacion de las entidades fuertes.- En principio las entidades fuertes del modelo EntidadRelación son transformados al modelo relacionalsiguiendo estas instrucciones:

Entidades. Las entidades pasan a ser tablas, con el mismonombreAtributos. Los atributos pasan a ser columnas o atributosde la tabla. Identificadores principales. Pasan a ser claves primariasIdentificadores candidatos. Pasan a ser claves candidatas.


CURSO 2011 - 2012 29

Transformación del Modelo E/R al Modelo Relacional

Ejemplo de transformación de Entidad


CURSO 2011 - 2012 30


Transformación de Relaciones Binarias.-Dependiendo del tipo de relación la transformación es diferente:Relaciones N:M.- la relación se transforma en una tabla cuyos atributos son: los atributos de la relación y las claves de las entidadesrelacionadas (que pasarán a ser claves externas). La clave de la tabla la forman todaslas claves externas.


CURSO 2011 - 2012 31


Ejemplo de transformación de RelaciónN:M

FACTURA Contiene PRODUCTO

Cod_Factura Fecha Cod_Producto PrecioCantidad

FACTURA(Cod_Factura, Fecha)FactContienePdto.(Cod_Factura, Cod_Producto, Cantidad)PRODUCTO(Cod_Producto, Precio)

(1,N) (1,N)


CURSO 2011 - 2012 32


Relaciones 1:M.- Las relaciones binarios de tipo unoa varios no requieren ser transformadas en una tablaen el modelo relacional. En su lugar la tabla del ladovarios (tabla relacionada) incluye como clave externa o foranea el identificador de la entidad del lado uno (tabla principal). ABSORCIÓN DE CLAVE o PROPAGACIÓN DE CLAVE.

Si la cardinalidad minima es 0 en lado uno, se podránadmitir valores nulos en la clave foranea.

Si existen atributos en la relación estos pasan a formar partede la tabla que absorve la clave


CURSO 2011 - 2012 33


Ejemplo de transformación de RelaciónN:M

FACTURA Emite CLIENTE

Cod_Factura Fecha Cod_Cliente Nombre

FACTURA(Cod_Factura, Fecha, Cod_Cliente )

CLIENTE(Cod_Cliente, Nombre)

(1,N) (1,1)


CURSO 2011 - 2012 34


Relaciones 1:1.- Dependiendo de la cardinalidad quetengan las entidades con respecto a la relación, tenemos:

Entidades con cardinalidad (1,1) en ambos casos, la relación no genera tabla, y se produce absorción de clave(clave foranea)por parte de una tabla a otra. La absorciónde clave de una tabla a otra dependerá de como se quieraorganizar la información para la realización de consulta. Siexisten atributos en la relación estos pasan a formar partede la tabla que absorve la clave. Ej: Empleado tieneVehiculo


CURSO 2011 - 2012 35


Ejemplo de transformación de Relación 1:1 con cardinalidades de las entidades (1,1)

EMPLEADO Tiene VEHICULO

Cod_Emp Nombre Matricula Modelo

EMPLEADO(Cod_Empleado, Nombre, Matricula )

VEHICULO(Matricula, Modelo)

(1,1) (1,1)


CURSO 2011 - 2012 36


Ejemplo de transformación de Relación 1:1 con cardinalidades de las entidades (1,1)

EMPLEADO Tiene VEHICULO

Cod_Emp Nombre Matricula Modelo

(1,1) (1,1)

EMPLEADO(Cod_Empleado, Nombre)

VEHICULO(Matricula, Modelo, Cod_Empleado )


CURSO 2011 - 2012 37


Alguna Entidad con cardinalidad (0,1), la relaciónno genera tabla, y se produce absorción de clavepor parte de una tabla a otra. La entidad queabsorve la clave es la que participa con cardinalidad (1,1) en la relación Ej: Enfermoingresado en Cama, Un enfermo si lo es debe estaringresado en una cama, y una cama puede que no este ocupado por ningún enfermo. En este caso esla entidad enfermo la que absorve la clave de la entidad Cama.


CURSO 2011 - 2012 38


Ejemplo de transformación de Relación 1:1 una entidad con cardinalidad (0,1)

ENFERMO Ingresado CAMA

Cod_Enfermo Nombre NºHab. Nºcama

ENFERMO(Cod_Enfermo, Nombre, NºHab, Nº cama )

CAMA(NºHab, Nº_cama, TipoCama)

(0,1) (1,1)

Tipo


CURSO 2011 - 2012 39


Ambas entidades con cardinalidad (0,1), Existendos alternativas:

La relación genera tabla, cuyos atributos son losatributos identificadores de las entidades, más lospropios de la relación, y la clave puede ser cualquierade los identificadores de las entidades que relacionaLa relación no genera tabla, se produce absorción de clave de una entidad sobre la otra, eso dependerá de como se quiera organizar la información.


CURSO 2011 - 2012 40


Ejemplo de transformación de Relación 1:1 con cardinalidades en las entidades (0,1)

CLIENTE Ocupa HABITACION

Cod_Cliente Nombre NºHab.

CLIENTE(Cod_Cliente, Nombre, NºHab )

HABITACION(NºHab,Tipo)

(0,1) (0,1)

Tipo


CURSO 2011 - 2012 41





(0,1) (0,1)

Tipo

CLIENTE(Cod_Cliente, Nombre )

HABITACION(NºHab,Tipo, Cod_Cliente )


CURSO 2011 - 2012 42





(0,1) (0,1)

Tipo

CLIENTE(Cod_Cliente, Nombre)ClOcupaHab(NºHab, CodCliente)HABITACION(NºHab,Tipo)


CURSO 2011 - 2012 43


Relaciones Reflexivas.- Las relaciones recursivas se tratan de la misma forma que las otras, sólo que un mismo atributopuede figurar dos veces en una tabla como resultado de la transformación (por eso es interesante indicar el rol en el nombre del atributo ). Dependiendo de las cardinalidades de la relación, tenemos:

Cardinalidad 1:1.- La relación no genera tabla, pero la entidad absorvela clave de la tabla. Cardinalidad 1:N.- Genera tabla si la cardinalidad de la entidad es(0,1), sino se produce una absorción de clave.Cardinalidad N:M.- La relación genera tabla, y la clave es la union de las claves con semántica diferente.


CURSO 2011 - 2012 44


Ejemplo de transformación de RelaciónReflexiva 1:1.

PERSONA Esta Casado

Dni Nombre

PERSONA(Dni, Nombre, Dni_Conyuge )

(0,1)(0,1)

1:1


CURSO 2011 - 2012 45


Ejemplo de transformación de RelaciónReflexiva 1:N.

CLIENTE Avala

Cod_Cliente Nombre

CLIENTE(Cod_Cliente, Nombre)ClAvalaCl(Cod_ClienteAvalado, Cod_ClienteAvalador)

(0,1)(0,N)

1:N


CURSO 2011 - 2012 46



PERSONA Es padre

Dni Nombre

PERSONA(Dni, Nombre, Dni_Padre)

(1,1)(0,N)

1:N


CURSO 2011 - 2012 47



CURSO Prerequisito

Cod_Curso Nombre

CURSO(Cod_Curso, Nombre, Descripción)CursoesPrerequisitoCurso(Cod_Curso, Cod_CursoPrerequ, Obligatorio)

(0,N)(0,N)

N:M

Obligatorio

Descripcion


CURSO 2011 - 2012 48


Relaciones N-arias (N>2).- Por lo general siempregeneran tabla. La tabla contendrá como campos losatributos clave de las entidades que participan en la relación más los atributos propios de la relación. La clave de la tabla estará formada por los atributosclave de las entidades que relaciona.Si una relación participa con cardinalidad máxima 1, puede que no tenga que formar parte de la clave de la nueva tabla.


CURSO 2011 - 2012 49


Ejemplo de transformación de Relación Ternaria N:M:J

PROVEEDOR Suministra PIEZA

Cod_Prov Nombre Cod_Pieza Descrip

PROVEEDOR(Cod_Prov, Nombre)PIEZA(Cod_Pieza, Descripción)ALMACEN(Cod_Almacen, Localización)Suministra(Cod_Prov, Cod_Pieza, Cod_Almacen)

(1,N) (1,N)

ALMACEN(1,N)

Cod_AlmacenLocaliza


CURSO 2011 - 2012 50


Ejemplo de transformación de Relación Ternaria N:M:1

PROFESOR Imparte ASIGNATURA

Cod_Prof Nombre Cod_Asig Nombre

PROFESOR(Cod_Prof, Nombre)ASIGNATURA(Cod_Asig, Nombre)GRUPO(Cod_Grupo, Titulación)Imparte(Cod_Asig, Cod_Grupo, Cod_Prof)

(1,1) (1,N)

GRUPO(1,N)

Cod-GrupoTitulacion


CURSO 2011 - 2012 51


Relaciones de dependencia.- No generantabla. La clave de la entidad fuerte debeintroducirse en la tabla de la entidad debil y formar parte de la clave de ésta (sobre todo sila dependencia es por identificación). Seráclave foranea


CURSO 2011 - 2012 52


Ejemplo de transformación de Relación de dependencia

HABITACIÓN CAMA

Nº Localizac NºHab. Nºcama

HABITACIÓN( Nº , Localización )

CAMA(NºHab, Nº_cama, TipoCama)

Tipo


CURSO 2011 - 2012 53


Relaciones ISA.- No tienen un mecanismo mátematico de transformación. Es conveniente y necesario la eliminación de las relaciones ISA como paso previo al proceso de transformación al modelo relacion.En el proceso de eliminación se podrán aplicar tres reglas o estrategias, la elección de una u otra dependerá de:

La magnitud de la relación ISA.- Nº atributos de las entidades subtipo, si una subentidad no tiene atributos propios, ni relaciones desaparece.El tipo de relación ISA.-Relación con otras entidades.- Si alguna subentidad mantiene relacióncon otra entidad, es aconsejable que no desaparezcaCriterios de procesamiento.- ¿Velocidad o Tamaño?


CURSO 2011 - 2012 54


En el proceso de eliminación de la relación ISA, se optará por una de estas estrategias:

1ª Regla:Eliminación de la entidad supertipo.-Normas:

Todos los atributos de la superentidad pasan a cada una de lasentidades subtipoLas relaciones que mantuviera la superentidad, pasan a a lasentidades subtipo, si la ISA es exclusiva, las subentidades tendráncardinalidad mínima 0, en estas relaciones.El identificador de la subentidad es el mismo que el de la superentidad (si la subentidad no tenia identificador propio)


CURSO 2011 - 2012 55


Eliminación de la entidad supertipo (cont.).-Cuando se puede aplicar:

Cuando la relación ISA es exclusiva totalInconvenientes:

Se introduce redundancia (atributos de la superentidadse duplican en las subentidades)Se pierde semántica (desaparece la superentidad)Nº de relaciones aumenta => Nº tablas aumentaLas operaciones de acceso requieren el manejo de varias entidades.


CURSO 2011 - 2012 56


Eliminación de la entidad supertipo (cont.).-Cuando es aconsejable aplicar:

Cuando la superentidad no se relaciona con nadieLa superentidad tiene pocos atributos


CURSO 2011 - 2012 57


2ª Regla:Eliminación de las entidades subtipo.-Normas:

Los atributos de las entidades subtipo pasan a la entidad supertipo.En la superentidad se añade un atributo, cuyos valores van a ser lostipos se subentidad (Atributo que generó la ISA)Las relaciones de las subentidades pasan a la superentidad, si la ISA era exclusiva, la cardinalidad minima en estas relaciones es 0, si era inclusiva, participará con la misma cardinalidad que lassubentidades.

Cuando se puede aplicar:En cualquier tipo de relación ISA


CURSO 2011 - 2012 58


2ª Regla:Eliminación de las entidades subtipo(cont.).-Inconvenientes:

Valores nulos en los atributos de la superentidad => Se desperdiciaespacioInformación no necesaria en el proceso de consultas.

Ventajas:Esquema más simple => Acceso a la información más rápido

Cuando es aconsejable aplicar:Cuando las subentidades no presentan muchas relaciones, ni tienenmuchos atributos propiosCuando la simplicidad del modelo supere los inconvenientes quepuede presentar


CURSO 2011 - 2012 59


3ª Regla:Eliminación de la relación ISA.-Normas:

La relación ISA se transforma en tantas relaciones 1:1, comosubentidades existanLas subentidades se convierten en entidades debiles.Las subentidades participan con cardinalidad minima 0 si la relación ISA era exclusiva y 0 ó 1 si era inclusiva.El identificador (clave foranea) de las subentidades es el mismoque el de la superentidadLa superentidad puede añadir el atributo que genera la ISA. Sininguna subentidad desaparece este atributo no es necesario.Se mantienen todas las relaciones de las subentidades y de la superentidad.


CURSO 2011 - 2012 60


3ª Regla:Eliminación de la relación ISA (cont.).-Normas:

Si la ISA es total, se debe prohibir la insercción de tuplas en la superentidad y se deberá crear un disparador que ante una inserción en la subentidadinserte en la superentidad (el atributo discriminante no puede tener valor nulo).Si la ISA es parcial, no hay que crear un disparador, nise prohibirá insercción en la superentidad, además el atributo discriminante podrá tener valores nulos.


CURSO 2011 - 2012 61


3ª Regla:Eliminación de la relación ISA (cont.).-Normas:

Si la ISA es exclusiva, es necesario una aserción quecompruebe que, si un ejemplar pertenece a uno de lossubtipos, entonces no puede pertenecer a los demás.Si la ISA es inclusiva, es necesaria una aserción similar a la de la exclusividad pero que dé cabida a nuevosvalores del atributo discriminante para los casos de solapamiento, comprobando que las ocurrencias estánen los subtipos adecuados.


CURSO 2011 - 2012 62


3ª Regla:Eliminación de la relación ISA (cont.).-Cuando se puede aplicar :

En cualquier caso, es la regla más general y muchasveces la más usada

Inconvenientes:El esquema resultante es bastante más complejo => Mayor tiempo en el acceso a la información

Ventajas:Esquema más rico semanticamente


CURSO 2011 - 2012 63


Ejemplo de transformación de relación ISA [enlace]


CURSO 2011 - 2012 64


Ejercicio.- Aplicar las tres reglas paratransformar la relación ISA referente al ejercicio5 de la hoja3


CURSO 2011 - 2012 65


Relaciones Exclusivas.- Se transforman igualque el resto de relaciones, pero es necesarioañadir un check que permita comprobar si un ejemplar de la entidad participa ya en unaocurrencia de la relación.


CURSO 2011 - 2012 66

6. NORMALIZACIÓN

Por lo general de la transformación del Modelo E/R al Modelo Relacional, se obtiene una “buena BD”.En algunas ocasiones, bien por fallos en el diseño (ME/R) o por problemas indetectables (enunciado, etc..), tendremos un esquema de BD que puede incorporar los siguientesproblemas:

Redundancia.- Se produce cuando los datos se repiten de forma continua e innecesaria por las tablas de la BD. Se detecta rapidamentee implica una revisión en el diseño de la BD.Ambigüedades.- Datos que no clarifican suficientemente el registro al que representan. Los datos de cada registro podrían referirse a más de un registro o incluso puede ser imposible saber a qué ejemplarexactamente se están refiriendo. Es un problema muy grave y difícil de detectar.


CURSO 2011 - 2012 67

Normalización

Pérdida de restricciones de integridad.-Normalmente debido a dependenciasfuncionales. Más adelante se explica esteproblema. Se arreglan fácilmente siguiendo unaserie de pasos concretos. Anomalías en operaciones de modificación, insercción y borrado de datos. El hecho de queal insertar un solo elemento haya que repetirtuplas en una tabla para variar unos pocos datos. O que al eliminar un elemento suponga eliminarvarias tuplas necesariamente.


CURSO 2011 - 2012 68

Normalización

Ejemplo:BD que almacena información sobre los libros de una librería (ISBN, Titulo, Idioma), quien los escribe (Nombre escritor, Dirección, Nacionalidad) y la editorial( Nombre Editorial, Nº empleados de la editorial) a la que pertenece.Consideramos las siguientes posibilidades:

a) ESCRITORES(Nombre, Dirección, Nacionalidad)LIBROS(ISBN, Titulo, Idioma, Nombre_Editorial)EDITORIAL( Nombre_Editorial, Nº _empleados)Escribir(Nombre-Escritor, ISBN-Libro)

b) ESCRIBE(Nombre-Escritor, Dirección, Nacionalidad, Isbn-Libro, Titulo, Idioma, Editorial, Nº empleados)

En el caso b) existe mucha redundancia


CURSO 2011 - 2012 69

Normalización

En los dos casos se recoge la misma información, pero de distinta forma. En el caso b) el identificador es Nombre-Escritor + Isbn-Libro (con lo que no pueden existir valores nulos de estos atributos). En el caso b) existe mucha redundancia (la nacionalidad del autor se repite por cada libro que ha escrito, averiguar más redundancia?). Esta redundancia produce:

Anomalías de inserción.- Refleja el hecho de no poder introducir en el sistema información. Ej: Dar de alta un escritor (que aun no ha escrito ningún libro) no es posible (valores nulos en el ident. Isbn-libro). Dar de alta un libro obliga a insertar tantas tuplas como autores tenga el libro.


CURSO 2011 - 2012 70

Normalización

Anomalías en la modificación.- Refleja el hecho de que la modificación de información en el mundo real implica múltiples modificaciones en el sistema. Ej: Modificar la dirección de un escritor implica modificarla para todas las tuplas de ese escritor, si no es así se producen inconsistencias.Anomalías de borrado.- Refleja el hecho de que al borrar una información, se pierde información necesaria. Ej: Borrar un autor implica borrar múltiples tuplas e incluso se puede borrar una editorial porque solo ha editado para ese autor.

Otros problemas como la imposibilidad de almacenar ciertos hechos. Ej: No se pueden introducir obras anónimas.


CURSO 2011 - 2012 71

Normalización

Cuando aparecen los problemas enumerados, se pueden resolver usando reglas de normalización. Estas reglas suelen forzar la división de una tabla en dos o más tablas para arreglar ese problema. Tª de la Normalización.- Formulada por Frank Codd y continuada por otros autores (Boyce, Fagin). consiste en definir una serie de reglas, denominadasFormas normales que aseguran una BD biendiseñada. Es una teoria puramente mátematica quejunto a la Teoria de Dependencias Funcionalesposibilitan el diseño correcto de BD.


CURSO 2011 - 2012 72

Normalización

Existen hasta 6 Formas Normales y si unatabla esta en FNx implica que tambien lo estaen las FN anteriores, pero no al reves.Para tener una BD bien diseñada basta con llegar a la FN Boyce-Codd (en orden la 4ª), la 4ª y la 5ª son polemicas.Las Formas Normales se aplican a las tablasdel modelo relacional


CURSO 2011 - 2012 73

Normalización

Conceptos de la Tª de Dependencias Funcionales:Dependencia Funcional (X->Y).- Un atributo/s Ydepende funcionalmente de otro/s X, si para cada valor de X, solo existe un valor de Y. Ej: Nombre depende de Dni, NumFactura no depende de Dni. A X se le denominadeterminante a Y implicado.Dependencia Funcional Completa (X=>Y).- Y debedepender de X y ademas X no se puede descomponer en más atributos. Ej: El Dni y Cod_Cliente producen unadependencia sobre Nombre, pero no es completa porque el Dni tambien produce una dependencia (en este casocompleta) sobre el Nombre.


CURSO 2011 - 2012 74

Normalización

Conceptos de la Tª de Dependencias Funcionales:Dependencia Funcional elemental .- Se produce cuandoX e Y forman una dependencia completa e Y es un únicoatributo.Dependencia Funcional Transitiva.- Se produce cuandose tienen tres cjtos. de atributos X,Y y Z. Y dependefuncionalmente de X (X→Y), Z depende funcionalmentede Y (Y→Z). Además X no depende funcionalmente de Y (Y-/→X). Entonces ocurre que X produce unadependencia funcional transitiva sobre Z y se representa(X - -> Z). Ej: Cod_Curso -> Cod_Tutor y Cod_Tutor->Cod_Departamento, pero Cod_Tutor -/-> Cod_Curso, entonces Cod_Curso - -> Cod_Departamento


CURSO 2011 - 2012 75

Normalización

Vs.

1ª Forma Normal (1FN).- Una tabla se encuentra en 1ª forma normal si impide que un atributo de una tupla pueda tomar más de un valor. Ej:


CURSO 2011 - 2012 76

Normalización

2ª Forma Normal (2FN).- Una tabla se encuentra en 2ª forma normal si lo esta en 1FN y además cada atributo que no sea clave, depende de forma funcional completa respecto de cualquiera de las claves. Si hay atributos que depende sólo de parte de la clave, entonces esa parte de la clave y esosatributos formarán otra tabla Ej:

Existe algún atributo que solo dependa de parte de la clave?


CURSO 2011 - 2012 77

Normalización

2ª Forma Normal (2FN).- Solución al ejemplo:


CURSO 2011 - 2012 78

Normalización

3ª Forma Normal (3FN).- Ocurre cuando una tabla está en 2FN y además ningún atributo que no sea clave dependetransitivamente de las claves de la tabla. Es decir no ocurrecuando algún atributo depende funcionalmente de atributosque no son clave. Ejemplo:

La provincia depende del Cod_Provincia


CURSO 2011 - 2012 79

Normalización

3ª Forma Normal (3FN).- Solución del ejemplo


CURSO 2011 - 2012 80

Normalización

Forma Normal de Boyce-Codd (FNBC).- Ocurre si unatabla está en tercera forma normal y además tododeterminante es una clave candidata. Ejemplo:

Un trabajador puede trabajar en varios dptos. En dicho dpto.puede haber varios responsables, pero un responsable solo lo debe ser de un departamento, Responsable -> Departamento. Se ha encontrado un determinante que no es clave candidata.


CURSO 2011 - 2012 81

Normalización

Forma Normal de Boyce-Codd (FNBC).- Solución del ejemplo: TRABAJADOR

Trabajador Departamento responsableAlexArturoCarlosGabrielaLuisaFelipa ProducciónMartín ProducciónJulio VentasHiginio ProducciónEva Ventas

TrabajadorTrabajaDepartamentoTrabajador DepartamentoAlex ProducciónArturo ProducciónCarlos VentasGabriela ProducciónLuisa Ventas


CURSO 2011 - 2012 82

Normalización

Forma Normal de Boyce-Codd (FNBC).- Solución del ejemplo:

TrabajadorTrabajaDepartamentoTrabajador DepartamentoAlex ProducciónArturo ProducciónCarlos VentasGabriela ProducciónLuisa Ventas


CURSO 2011 - 2012 83

Normalización

Ejercicios [ enlace ]

Gbd02_tema 4. El Modelo Relacional

Documents

Transcript of Gbd02_tema 4. El Modelo Relacional