Manual 2 Bases de Datos E-R al Modelo Relacional (Paso a Tablas) PDF

MANUAL 2 BASES DE DATOS TRANSFORMACIÓN DEL MODELO ENTIDAD-RELACIÓN (E/R) AL MODELO RELACIONAL (PASO A TABLAS) Manual 2. Bases de Datos: Transformación del Modelo E/R al modelo relacional (Paso a tablas) 1. Introducción...............................................................

MANUAL 2 BASES DE DATOS TRANSFORMACIÓN DEL MODELO ENTIDAD-RELACIÓN (E/R) AL MODELO RELACIONAL (PASO A TABLAS) Manual 2. Bases de Datos: Transformación del Modelo E/R al modelo relacional (Paso a tablas) 1. Introducción.......................................................................................................................... 2 2. Simplificar nuestro diagrama E/R........................................................................................ 2 3. Transformar el diagrama E/R al modelo relacional............................................................ 3 3.1. Transformación de entidades (no débiles).................................................................. 3 3.2. Transformación de atributos........................................................................................ 3 3.3. Transformación de entidades débiles.......................................................................... 3 3.4. Transformación de relaciones...................................................................................... 4 3.5. Transformación de relaciones reflexivas..................................................................... 7 3.6. Transformación de jerarquías...................................................................................... 9 4. Normalización. Formas Normales...................................................................................... 11 4.1. Primera forma normal (1FN)...................................................................................... 12 4.2. Segunda forma normal (2FN)..................................................................................... 13 4.3. Tercera forma normal (3FN)....................................................................................... 14 5. Grafo Relacional................................................................................................................. 15 1 Manual 2. Bases de Datos: Transformación del Modelo E/R al modelo relacional (Paso a tablas) 1. Introducción El diagrama E/R, permite una gran independencia de las cuestiones relativas a la implementación física de la base de datos. El tipo de SGBD, las herramientas software, las aplicaciones, lenguajes de programación o hardware disponible no afectarán, al menos hasta el momento, a los resultados de esta fase. Nuestro esquema conceptual habrá sido revisado, modificado y probado para verificar que se cumplen adecuadamente todos y cada uno de los requerimientos del problema a modelar. Este esquema representará el punto de partida para la siguiente fase, el diseño lógico de la base de datos. El diseño lógico consistirá en la construcción de un esquema de la información relativa al problema, basado en un modelo de base de datos concreto. Estos modelos podrán ser: el modelo en red, el modelo jerárquico y, sobre todo, el modelo relacional y el modelo orientado a objetos. Nosotros nos centraremos en el modelo relacional y para conseguirlo a partir de nuestro diagrama E/R debemos realizar los siguientes pasos: - Simplificar nuestro diagrama E/R. - Transformarlo al modelo relacional. - Aplicar normalización y así obtendremos lo que se conoce como el paso a tablas del esquema conceptual o, lo que es lo mismo, el esquema lógico. Desde ese momento, basándonos en este esquema, podremos llevarnos nuestra base de datos a cualquier SGBD basado en el modelo relacional e implementarla físicamente. Esta implementación física será totalmente dependiente de las características del SGBD elegido. 2. Simplificar nuestro diagrama E/R Aplicando una serie de pautas el proceso de transformación al modelo lógico basado en el modelo relacional será fácil y fiable. Para ello simplificaremos nuestro diagrama E/R con las siguientes transformaciones: a) Transformación de atributos compuestos: Los atributos compuestos de una entidad han de ser descompuestos en los atributos simples por los que están formados. Por ejemplo, si en una entidad EMPLEADO consideramos que el atributo “Nombre_completo” es un atributo compuesto formado por “Nombre”, “Apellido1” y “Apellido2” deberemos descomponerlo en tres atributos simples. b) Transformación de atributos multivaluados: Si nuestro diagrama incluye la existencia de un atributo multivaluado, este se ha de convertir en una entidad relacionada con la entidad de la que procede. Para esta nueva entidad se elegirá un nombre adecuado y tendrá un único atributo (el correspondiente al antiguo atributo múltiple). Este atributo es posible que funcione correctamente como clave primaria de la entidad, pero a veces es posible que no. En este caso, la entidad que hemos creado puede que sea débil. Deberemos ajustar en cualquier caso correctamente las claves primarias. Por ejemplo, si en una entidad EMPLEADO consideramos que el atributo “Email” es un atributo multivaluado porque puede tener varios correos electrónicos pues sería adecuado realizar una nueva entidad EMAIL que sería una entidad débil de EMPLEADO. 2 Manual 2. Bases de Datos: Transformación del Modelo E/R al modelo relacional (Paso a tablas) 3. Transformar el diagrama E/R al modelo relacional Para realizar el paso al modelo de datos Relacional se deben tener en cuenta las siguientes cuestiones: En este apartado vamos a ir haciendo pequeños ejemplos para ir aclarando cada paso a realizar. 3.1. Transformación de entidades (no débiles). Toda entidad se transforma en una relación o tabla: Cada tipo de entidad se debe convertir a una relación, es decir, será necesario crear una tabla para cada entidad que parezca en el diagrama E/R. 3.2. Transformación de atributos. Todo atributo se transforma en columna dentro de una tabla: Cada atributo de una entidad se debe transformar en una columna en la relación a la que ha dado lugar la entidad. El atributo o atributos principales (los que actúan como identificador de la entidad) pasar a ser la clave principal de la relación y se subrayarán para identificarla como la clave principal de la relación (tabla). Además, deben ser no nulos. El resto pasan a ser otras columnas de la tabla pudiendo ser o no ser nulos. EJEMPLO PRÁCTICO: Tenemos la entidad siguiente EMPLEADO. EMPLEADO (NIF, Nombre, Apellido1, Apellido2, Teléfono) 3.3. Transformación de entidades débiles. Convertir toda entidad débil a fuerte: Convertir una entidad débil en fuerte consiste en hacer que cada entidad débil genere una tabla que incluirá todos sus atributos, añadiéndose a ésta los atributos que son clave primaria de la entidad fuerte con la que esté relacionada. Estos atributos añadidos se constituyen como clave foránea que referencia a la entidad fuerte. Seguidamente, se escogerá una clave primaria para la tabla creada. 3 Manual 2. Bases de Datos: Transformación del Modelo E/R al modelo relacional (Paso a tablas) EJEMPLO PRÁCTICO: Tenemos la entidad EMPLEADO y la entidad débil HIJO. EMPLEADO (NIF, Nombre, Apellido1, Apellido2, Teléfono) HIJO (NIF, Nombre_hijo, Fecha_Nacimiento) 3.4. Transformación de relaciones. Dependen del tipo de relación que se trate: a) Relaciones N:M: Se transforman en una relación que tendrá como clave primaria la concatenación de los atributos principales de cada una de las entidades que relacionan que serán clave ajena respecto a cada una de las tablas donde ese atributo es clave primaria. Habrá que considerar lo que ocurre en los casos en los que se borre o modifique la clave primaria referenciada. EJEMPLO PRÁCTICO: Tenemos la entidad EMPLEADO y la entidad PROYECTO relacionadas con la relación “trabaja_en” que es una relación muchos a muchos ya que entendemos que un empleado puede trabajar en muchos proyectos y que en un proyecto pueden trabajar muchos empleados. Por lo que tendríamos que realizar las tablas EMPLEADO con sus atributos, PROYECTO con sus atributos y trabaja_en con las claves principales de las dos entidades anteriores además de sus atributos propios siendo la clave primaria mínima la combinación de las dos claves. EMPLEADO (NIF, Nombre, Apellido1, Apellido2, Teléfono,) trabaja_en (NIF, Num_Proyecto, Horas) PROYECTO (Num_Proyecto, Nombre_Proyecto) 4 Manual 2. Bases de Datos: Transformación del Modelo E/R al modelo relacional (Paso a tablas) b) Relaciones 1:N: Existen dos soluciones y siempre teniendo en cuenta en ambas soluciones las referencias ajenas y las actuaciones en caso de borrado y modificación. o Propagar el atributo principal de la entidad que tiene cardinalidad máxima 1 a la que tienen N, y hacer desaparecer la relación como tal. o Transformarla en una relación como si fuese una de tipo N:M. Sólo es recomendable en tres casos, 1) si es posible que aparezcan muchos nulos porque existen pocos elementos relacionados, 2) cuando se prevé que dicha relación pasará en un futuro a ser de tipo N:M y 3) cuando la relación tiene atributos propios. EJEMPLO PRÁCTICO: Tenemos la entidad EMPLEADO y la entidad DEPARTAMENTO relacionadas con la relación “pertenece” que es una relación uno a muchos ya que entendemos que un empleado sólo puede estar en un departamento y que un departamento puede tener muchos empleados. Así que nos interesa propagar el atributo principal de la entidad con cardinalidad máxima 1 (Num_Dpto de la entidad DEPARTAMENTO) a la entidad con cardinalidad N (EMPLEADO) y la relación la haremos desaparecer. EMPLEADO (NIF, Nombre, Apellido1, Apellido2, Teléfono, Num_Dpto) DEPARTAMENTO (Num_Dpto, Nombre_Dpto) 5 Manual 2. Bases de Datos: Transformación del Modelo E/R al modelo relacional (Paso a tablas) c) Relaciones 1:1: Puesto que se trata de una particularización de cualquiera de los dos casos anteriores, se pueden igualmente o generar una nueva tabla o propagar la clave en función de la cardinalidad de las entidades de la siguiente forma: o Si tenemos las cardinalidades (1,1) : (1,1) entonces propagamos la clave en la dirección que queramos y no pasamos a tabla la relación. o Si tenemos las cardinalidades (0,1) : (1,1) entonces propagamos la clave hacia el (0,1) y no pasamos a tabla la relación. o Si tenemos las cardinalidades (1,1) : (0,1) (ídem que el caso anterior) entonces propagamos la clave hacia el (0,1) y no pasamos a tabla la relación. o Si tenemos las cardinalidades (0,1) : (0,1) entonces se crea la tabla a la relación. EJEMPLO PRÁCTICO: Tenemos la entidad ALUMNO y la entidad EXPENDIENTE relacionadas con la relación “tienen” que es una relación uno a uno con las cardinalidades que vemos en la imagen ya que entendemos que un alumno puede tener o no un expediente, pero sólo uno y cada expediente pertenece a un solo alumno. En este caso propagamos la clave de ALUMNO a la entidad EXPEDIENTE y no tenemos que pasar a tabla la relación “tienen”. ALUMNO (NIF, Nombre, Apellido1, Apellido2, Teléfono) EXPENDIENTE (Num_Expediente, Documento, NIF) EJEMPLO PRÁCTICO: Tenemos la entidad HOMBRE y la entidad MUJER relacionadas con la relación “se_casan” que es una relación uno a uno con las cardinalidades que vemos en la imagen. En este caso haríamos la tabla de la relación “se_casan”. 6 Manual 2. Bases de Datos: Transformación del Modelo E/R al modelo relacional (Paso a tablas) HOMBRE (NIF_hombre, Nombre_hombre) se_casan (NIF_hombre, NIF_mujer, Fecha_boda) MUJER (NIF_mujer, Nombre_mujer) Atributos de relaciones: Si la relación se transforma en una tabla, todos sus atributos pasar a ser columnas de la tabla. Si alguno de los atributos de la relación es principal, entonces deberá ser incluido como parte de la clave primaria en dicha tabla. EJEMPLO PRÁCTICO: Esto ya lo hemos ido viendo en ejemplos anteriores de este mismo apartado 3.4. 3.5. Transformación de relaciones reflexivas. Las relaciones reflexivas o cíclicas podrán generar una o varias tablas en función de la cardinalidad de la relación. a) Relación 1:1. La clave de la entidad se repite, con lo que la tabla resultante tendrá dos veces ese atributo, una como clave primaria y otra como clave ajena de la misma. EJEMPLO PRÁCTICO: Tenemos la entidad PERSONA que tendrá los datos de una persona siendo el NIF la clave primaria y tenemos también la relación “es_cónyuge”. Es una relación 1:1 reflexiva. Así que cada fila contendrá el DNI y todos los datos de una persona, siendo el DNI la llave primaria, y, además otro campo DNI_CONYUGE que será el DNI del cónyuge. PERSONA (NIF_persona, Nombre_persona, NIF_conyugue) 7 Manual 2. Bases de Datos: Transformación del Modelo E/R al modelo relacional (Paso a tablas) b) Relación 1:N. Tendríamos dos casos distintos: o Si la entidad muchos es siempre obligatoria, actuaremos con en el caso 1:1. o Si la entidad muchos no es obligatoria se creará una nueva tabla cuya clave será la de la entidad del lado muchos, y se propaga la clave hacia esta nueva tabla como clave foránea. EJEMPLO PRÁCTICO: Tenemos la entidad MÚSICO y la relación “dirige” donde no se considera obligatorio. Por la tanto se crea la tabla “dirige” y se propaga la clave hacia esta nueva tabla. MÚSICO (NIF, Nombre) dirige (NIF, NIF_director) c) Relación M:N. Se trataría como una relación binaria entre dos entidades por lo que se crearía una nueva tabla que tendría dos veces la clave primaria de la entidad. La clave de esta tabla será la combinación de ambas claves primarias. Si hubiera atributos asociados a la relación, se asociarían a esta nueva tabla. EJEMPLO PRÁCTICO: Tenemos la entidad PIEZA y la entidad “compone” del tipo N:M. PIEZA (Cod, Descripción) PIEZA_COMPUESTA (Cod, Cod_componente) 8 Manual 2. Bases de Datos: Transformación del Modelo E/R al modelo relacional (Paso a tablas) 3.6. Transformación de jerarquías. Para tratar las jerarquías tenemos la opción de hacerlo de tres formas distintas según cómo sea la jerarquía: a) Crear una única relación o tabla que aglutine todos los subtipos: En ella se incluirán todos los atributos del supertipo y de los subtipos. Esto permite mayor simplicidad, aunque puede provocar valores nulos en los atributos propios de cada subtipo. Por este motivo no es una opción que suela utilizarse. EJEMPLO PRÁCTICO: Tenemos la entidad EMPLEADO como supertipo y GERENTE, INFORMÁTICO Y ADMINISTRATIVO como subtipos como vemos en la imagen inferior. Utilizando esta opción sólo haríamos la tabla EMPLEADO con todos los atributos del supertipo y de los subtipos. EMPLEADO (DNI, Nombre, Teléfono, Año_Alta_Gerencia, especialidad, titulación, tipo) donde “tipo” se podría representar por ejemplo con 0 para el subtipo “GERENTE”, 1 para el subtipo “INFORMÁTICO” y 2 para el subtipo “ADMINISTRATIVO” b) Crear relación o tabla para todos tanto el supertipo como los subtipos: En la de los subtipos se coloca la clave primaria de la entidad supertipo. Se puede usar en cualquier caso y sobre todo cuando la especialización es total y exclusiva. EJEMPLO PRÁCTICO: Tenemos la entidad PERSONA como supertipo y HOMBRE Y MUJER como subtipos como vemos en la imagen inferior. 9 Manual 2. Bases de Datos: Transformación del Modelo E/R al modelo relacional (Paso a tablas) PERSONA (DNI, Nombre, Fecha_Nacimiento) HOMBRE (DNI, Testosterona) MUJER (DNI, Progesterona) c) Crear relación o tabla sólo para los subtipos: En este caso los subtipos heredan todos los atributos del supertipo. Igualmente que en el apartado b) esta opción se puede usar cuando la especialización es total y exclusiva y se utiliza, sobre todo, si el supertipo o padre no tiene relaciones y son los hijos los que se relacionan por su cuenta. EJEMPLO PRÁCTICO: Tenemos el mismo ejemplo del apartado b) y quedaría de la siguiente forma en este caso. HOMBRE (DNI, Nombre, Fecha_Nacimiento, Testosterona) MUJER (DNI, Nombre, Fecha_Nacimiento, Progesterona) 10 Manual 2. Bases de Datos: Transformación del Modelo E/R al modelo relacional (Paso a tablas) 4. Normalización. Formas Normales. La teoría de la normalización tiene como fundamento el concepto de formas normales diciendo que una relación está en una determinada forma normal si satisface un cierto conjunto de restricciones. Uno de los objetivos de una estructura de tabla normalizada es minimizar el número de "celdas vacías". Grupos de información son almacenados en distintas tablas que luego pueden ser "juntadas" (relacionadas) basándose en los datos que tengan en común. Es necesario que, al realizar la estructura de una base de datos, esta sea flexible. La flexibilidad está en el hecho que se puedan agregar datos al sistema posteriormente sin tener que rescribir lo que ya se tiene. Por lo tanto, no tendremos que modificar la estructura de nuestras tablas actuales, simplemente agregar lo que hace falta. La eficiencia se refiere al hecho de que no se tiene duplicación de datos, y tampoco tienen grandes cantidades de "celdas vacías". El objetivo principal del diseño de bases de datos es generar tablas que modelan los registros en los que se guardará la información. Es importante que esta información se almacene sin redundancia para que se pueda tener una recuperación rápida y eficiente de los datos. Se puede decir que los principales objetivos de la normalización son: - Controlar la redundancia de la información. - Evitar pérdidas de información. - Capacidad para representar toda la información. - Mantener la consistencia de los datos. La normalización es una técnica para diseñar la estructura lógica de los datos de un sistema de información en el modelo relacional, desarrollada por E. F. Codd en 1972. Es una estrategia de diseño de abajo a arriba: se parte de los atributos y éstos se van agrupando en relaciones (tablas) según su afinidad. Es como una etapa posterior a la correspondencia entre el esquema conceptual y el esquema lógico, que elimine las dependencias entre atributos no deseadas. Las ventajas de la normalización son las siguientes: - Evita anomalías en inserciones, modificaciones y borrados. - Mejora la independencia de datos. - No establece restricciones artificiales en la estructura de los datos. Uno de los conceptos fundamentales en la normalización es el de dependencia funcional. Una dependencia funcional es una relación entre atributos de una misma relación (tabla). La dependencia funcional es una noción semántica. Si hay o no dependencias funcionales entre atributos lo determinan los modelos mentales del usuario y las reglas de negocio de la organización o empresa para la que se desarrolla el sistema de información. Cada dependencia funcional es una clase especial de regla de integridad y representa una relación de uno a muchos. Por ejemplo: DNI  Nombre y Apellidos. También es necesario conocer los conceptos de: (considerando X, Y, Z atributos.) Dependencia funcional reflexiva: Si “Y” está incluido en “X” entonces X → Y Por ejemplo: Si dirección y nombre están incluidos en DNI entonces con el DNI se puede recuperar la dirección y el nombre. 11 Manual 2. Bases de Datos: Transformación del Modelo E/R al modelo relacional (Paso a tablas) Dependencia Funcional Aumentativa: Si “X” → “Y” entonces “XZ” → «YZ” Por ejemplo: DNI → Nombre DNI, Dirección → Nombre, Dirección Dependencia Funcional Transitiva: Si “X” → “Y” → Z” entonces “X” → “Z” Fecha de nacimiento → Edad Edad → Conducir Fecha de nacimiento → Edad → Conducir Dependencia Funcional Completa: Se dice que el atributo Y de la relación R es por completo dependiente funcionalmente del atributo X de R si depende funcionalmente de X y no depende funcionalmente de ningún subconjunto propio de X. La normalización se lleva a cabo en una serie de pasos. Cada paso corresponde a una forma normal que tiene unas propiedades. Conforme se va avanzando en la normalización, las relaciones tienen un formato más estricto (más fuerte) y, por lo tanto, son menos vulnerables a las anomalías de actualización. El modelo relacional sólo requiere un conjunto de relaciones en primera forma normal. Las restantes formas normales son opcionales. Sin embargo, para evitar las anomalías de actualización, es recomendable llegar al menos a la tercera forma normal. En este manual nos centraremos en llegar a la 3FN, aunque en los temas teóricos veremos la definición de todas las formas normales. 4.1. Primera forma normal (1FN) Una tabla está en Primera Forma Normal (1FN o FN1) sí, y sólo sí, todos los atributos de la misma contienen valores atómicos, es decir, no hay grupos repetitivos. Dicho de otra forma, estará en 1FN si los atributos no clave, dependen funcionalmente de la clave. Por lo general la mayoría de las relaciones cumplen con estas características, así que podemos decir que la mayoría de las relaciones se encuentran en la primera forma normal. 12 Manual 2. Bases de Datos: Transformación del Modelo E/R al modelo relacional (Paso a tablas) ¿Cómo se normaliza a Primera Forma Normal? a. Se crea, a partir de la tabla inicial, una nueva tabla cuyos atributos son los que presentan dependencia funcional de la clave primaria. La clave de esta tabla será la misma clave primaria de la tabla inicial. Esta tabla ya estará en 1FN. b. Con los atributos restantes se crea otra tabla y se elige entre ellos uno que será la clave primaria de dicha tabla. Comprobaremos si esta segunda tabla está en 1FN. Si es así, la tabla inicial ya estará normalizada a 1FN y el proceso termina. Si no está en 1FN, tomaremos la segunda tabla como tabla inicial y repetiremos el proceso. EJEMPLO PRÁCTICO: Si hemos seguido las instrucciones del apartado 2 del manual para evitar los atributos compuestos y multivaluados llegaremos a este punto encontrándonos en la primera forma normal ya que todos los atributos tendrán valores atómicos. Si suponemos que no hemos hecho lo anterior podremos encontrarnos la entidad ALUMNO: ALUMNO (NIF, Nombre, Fecha_nacimiento, Teléfonos*) Consideramos que Teléfonos es un atributo multivaluado que puede tener varios valores por lo que para tenerlo en la 1FN procedemos de la siguiente manera: a. Dejamos la tabla con los atributos clave más los atributos clave que dependan funcionalmente de la clave, es decir, en este caso los que no son multivaluados. ALUMNO1 (NIF, Nombre, Fecha_nacimiento) b. Hacemos otra tabla con los atributos clave más el atributo que no cumplía la dependencia funcional (el atributo multivaluado) y se amplía la clave. ALUMNO2 (NIF, Teléfonos) 4.2. Segunda forma normal (2FN) Una relación está en 2FN si y sólo si está en 1FN y todos los atributos no clave tienen dependencia funcional completa de la clave primaria. De acuerdo con esta definición, cada tabla que tiene un atributo único como clave, está en segunda forma normal. ¿Cómo se normaliza a Segunda Forma Normal? a. Se crea, a partir de la tabla inicial, una nueva tabla con los atributos que dependen funcionalmente de forma completa de la clave. La clave de esta tabla será la misma clave primaria de la tabla inicial. Esta tabla ya estará en 2FN. b. Con los atributos restantes, se crea otra tabla que tendrá por clave el subconjunto de atributos de la clave inicial de los que dependen de forma completa. Se comprueba si esta tabla está en 2FN. Si es así, la tabla inicial ya está normalizada y el proceso termina. Si no está en 2FN, tomamos esta segunda tabla como tabla inicial y repetiremos el proceso. EJEMPLO PRÁCTICO: Hagamos hincapié en que esto sólo será necesario si la clave primaria está formada por varios atributos. Si la clave primaria es un solo atributo no hacemos nada porque ya estaría en 2FN. 13 Manual 2. Bases de Datos: Transformación del Modelo E/R al modelo relacional (Paso a tablas) Supongamos que tenemos la relación RESERVA de la siguiente manera donde un cliente ha reservado un determinado coche para su alquiler: RESERVA (DNI_conductor, Matrícula, Nombre_conductor, Fecha_nacimiento, Fecha_permiso, Codigo_Marca_coche, Marca_coche, Modelo, Color) a. Haríamos una tabla con los atributos clave y los atributos no primos (cuando decimos atributos no primos nos referimos a los que no pertenecen a la clave principal) que cumplan la dependencia funcional completa. En este caso: RESERVA1 (DNI_conductor, Matrícula) b. Haríamos una tabla por cada subconjunto de atributos clave y sus atributos no primos que dependan de cada uno de ellos. En este caso: RESERVA2 (DNI_conductor, Nombre_conductor, Fecha_nacimiento, Fecha_permiso) RESERVA3 (Matrícula, Codigo_Marca_coche, Marca_coche, Modelo, Color) Y renombraríamos las tablas con otros nombres, por ejemplo: RESERVA1 = RESERVA RESERVA2 = CONDUCTOR RESERVA3= VEHÍCULO 4.3. Tercera forma normal (3FN) Una relación está en 3FN si y solo si está en 2FN y todos sus atributos no clave dependen no transitivamente de la clave primaria. Dicho de otro modo, si y sólo si los atributos no clave son mutuamente independientes y son dependientes por completo de la clave primaria. ¿Cómo se normaliza a Tercera Forma Normal? a. Se crea, a partir de la tabla inicial, una nueva tabla con los atributos que no poseen dependencias transitivas de la clave primaria. Esta tabla ya estará en 3FN. b. Con los atributos restantes, se crea otra tabla con los dos atributos no clave que intervienen en la dependencia transitiva, y se elige uno de ellos como clave primaria, si cumple los requisitos para ello. Se comprueba si esta tabla está en 3FN. Si es así, la tabla inicial ya está normalizada y el proceso termina. Si no está en 3FN, tomamos esta segunda tabla como tabla inicial y repetiremos el proceso. EJEMPLO PRÁCTICO: Si nos fijamos en el ejemplo anterior: RESERVA (DNI_conductor, Matrícula) CONDUCTOR (DNI_conductor, Nombre_conductor, Fecha_nacimiento, Fecha_permiso) VEHÍCULO (Matrícula, Codigo_Marca_coche, Marca_coche, Modelo, Color) Observamos que RESERVA Y CONDUCTOR ya están en 3FN porque no hay dependencias funcionales transitivas, pero en VEHÍCULO sí encontramos una dependencia funcional transitiva ya que: Matrícula  Codigo_Marca_coche  Marca_coche 14 Manual 2. Bases de Datos: Transformación del Modelo E/R al modelo relacional (Paso a tablas) Así que procedemos de la siguiente forma: a. Dejamos la tabla con su atributo clave y los atributos no primos que no tiene dependencia funcional transitiva. VEHÍCULO1 (Matrícula, Codigo_Marca_coche, Modelo, Color) b. Creamos otra tabla con los atributos no primos que tienen dependencia funcional transitiva y ponemos como clave el atributo no primo que aparece en la tabla anterior. VEHÍCULO2 (Codigo_Marca_coche, Marca_coche) Y renombraríamos las tablas con otros nombres, por ejemplo: VEHÍCULO1 = VEHÍCULO VEHÍCULO2 = MARCA 5. Grafo Relacional Una forma de representar gráficamente el esquema relacional de una manera sencilla y completa es el denominado grafo relacional. Es un grafo compuesto de un conjunto de nodos multiparticionados, donde cada nodo representa un esquema de relación, es decir, una tabla de la BD. Para cada tabla, como mínimo, ha de aparecer su nombre y sus atributos, indicando su clave primaria (subrayando los atributos que la componen). Se dibuja, además, un conjunto de arcos que conectan los atributos que constituyen la clave ajena con la tabla referenciada, permitiendo así que el usuario entienda los campos clave que comparten dominios comunes; en definitiva, los arcos representan la referenciabilidad de los atributos (clave ajena) de una relación respecto a la clave primaria de la otra. Los arcos están direccionados de modo que el arco parta de la clave ajena y la flecha señale a la tabla referenciada. Se siguen las siguientes reglas para realizar el grafo relacional: - Los nombres de las tablas se representan en mayúsculas y, a continuación, sus atributos entre paréntesis. - Las claves primarias aparecen subrayadas y las claves alternativas aparecen en negrita. - Las claves ajenas pueden representarse en cursiva y referencian a la relación en la que son clave primaria mediante una flecha. - Los atributos que pueden tomar valores nulos aparecen con un asterisco. - Las opciones para la integridad referencial que podemos incluir (aunque no es habitual incluirlas) son: o B:C  Borrado en cascada. o B:N  Borrado con puesta a nulos. o B:D  Borrado con puesta a valor por defecto. o B:R  Borrado restringido. o M:C  Modificación en cascada. o M:N  Modificación con puesta a nulos. o M:D  Modificación con puesta a valor por defecto. o M:R  Modificación restringido. 15 Manual 2. Bases de Datos: Transformación del Modelo E/R al modelo relacional (Paso a tablas) EJEMPLO PRÁCTICO: Modelar la relación entre personas, viviendas y municipios. Cada persona sólo puede estar empadronada en un único municipio, y habitar en una vivienda, pero puede ser propietaria de varios inmuebles. Su modelo E/R sería el siguiente: Del cual obtendríamos las siguientes relaciones o tablas: PERSONA (DNI, nombre, sexo) TELEFONOS (DNI, teléfono) (Aquí hemos separado en una tabla nueva ya que puede tener varios teléfonos, de esta manera sí se cumple la Primera Forma Normal) VIVIENDA (numreg, calle, num, piso, superficie, código) MUNICIPIO (código, nombre) EMPADRONADA (DNI, código, fecha) HABITA (DNI, numreg, fecha) PROPIEDAD (DNI, numreg) Y el GRAFO RELACIONAL sería el siguiente: 16 Manual 2. Bases de Datos: Transformación del Modelo E/R al modelo relacional (Paso a tablas) TELEFONOS (DNI_Persona, teléfono) HABITA (DNI_Persona, numreg, fecha) PERSONA (DNI, nombre, sexo) PROPIEDAD (DNI_Persona, numreg) EMPADRONADA (DNI_Persona, código, fecha) MUNICIPIO (código, nombre) VIVIENDA (numreg, calle, num, piso, superficie, código) 17