Diseño Lógico: Normalización

Transcription

GESTIÓN DE BASES DE DATOSDISEÑO LÓGICO:NORMALIZACIÓNFrancisco Pérezfranciscoprdv@gmail.comEsta obra está bajo una licencia de Creative CommonsReconocimiento-NoComercial-CompartirIgual 4.0 Internacional

CONTENIDOS1.2.3.4.5.6.7.NOMENCLATURA UTILIZADA EN EL MODELADO DE DATOSNORMALIZACIÓN Y FORMAS NORMALESPRIMERA FORMA NORMALSEGUNDA FORMA NORMALTERCERA FORMA NORMALFORMA NORMAL DE BOYCE-CODDDENORMALIZACIÓN

NORMALIZACIÓN1. NOMENCLATURA UTILIZADA EN EL MODELADO DE Atributo claveClave primariaEntidadesRelacionesLenguaje natural

NORMALIZACIÓN2. NORMALIZACIÓN Y FORMAS NORMALES

NORMALIZACIÓN2. NORMALIZACIÓN Y FORMAS NORMALESDurante la etapa de modeladológico, tras la obtención delmodelo relacional, suele sernecesario realizar una etapa denormalización, que permiteobtener un modelo lógicooptimizado.Para llevar una base de datos auna forma normal hay queimponer una serie derestricciones a los atributos delmodelo relacional.La normalización consiste en unaserie de refinamientos realizadossobre el modelo lógico.Una forma normal o formanormalizada es un parámetroque permite medir la calidad deldiseño de una base de datos.Existen 6 formas normales.Conforme se alcanzan formasnormales superiores, el diseñomejora conteniendo laredundancia, compartimentandola información y eliminandoanomalías.Para alcanzar una forma normalde orden 'n', primero esnecesario haber alcanzado laforma normal de orden inferior,'n-1'.

NORMALIZACIÓN2. NORMALIZACIÓN Y FORMAS NORMALES2.1. OBJETIVOS DE LA NORMALIZACIÓNLimita malías deldiseñoProporcionaintegridad

NORMALIZACIÓN2. NORMALIZACIÓN Y FORMAS NORMALES2.2. DEPENDENCIA FUNCIONALDEPENDENCIAFUNCIONALDada una relación que contienelos atributos 'X' e 'Y', se dice que'Y' depende funcionalmente de'X' (o que 'X' determina a 'Y',representándolo como X Y), sipara cada valor de 'X' hayasociado un único valor de 'Y'.Esto es equivalente a decir que siX Y, para cada valor de 'X',existe un único valor de 'Y'Si X Y, cuando dos tuplas deuna relación tienen el mismovalor para un atributo 'X',forzosamente han de tener elmismo valor para el atributo 'Y'(lo contrario no tiene porqué sercierto).

NORMALIZACIÓN2. NORMALIZACIÓN Y FORMAS NORMALES2.2. DEPENDENCIA FUNCIONALEJEMPLO DE DEPENDENCIA FUNCIONAL En la siguiente tabla se muestran datos de películas:Cód PelículaTítuloAñoDuración1Star Wars I19801206Star Trek XI20071337Back to the future1985979Matrix Revolutions2007102 Si nos fijamos en la primera fila, el atributo Cód Película 1 identifica a una película con un título, año yduración determinada. Siempre que se haga referencia al atributo Cod Película con valor 1, tendremosque los valores de los atributos Titulo, Año y Duración son siempre los mismos. Por tanto, Cód Película determina a Título, Año y a Duración (o lo que es lo mismo, Título, Año y Duracióntienen dependencia funcional respecto a Cód Película):Cód PelículaTítuloCód PelículaAñoCód PelículaDuración

NORMALIZACIÓN2. NORMALIZACIÓN Y FORMAS NORMALES2.2. DEPENDENCIA FUNCIONALCONTRAEJEMPLO DE DEPENDENCIA FUNCIONAL En la siguiente tabla se muestran datos de películas:Cód Película TítuloAñoDuración1Star Wars I19801206Star Trek XI20071337Back to the future1985979Matrix Revolutions2007102Si buscamos todas las filas en las que Año 2007, los valores de Cód Película, Título y Duración no son losmismos siempre en todas las filas (hay o puede haber varias películas distintas en ese mismo año). Portanto:AñoCód PelículaAñoTítuloAñoDuración

NORMALIZACIÓN2. NORMALIZACIÓN Y FORMAS NORMALES2.3. DEPENDENCIA FUNCIONAL COMPLETADEPENDENCIAFUNCIONALCOMPLETADada una relación que contiene losatributos:X1, X2, X3, , Xi, , Xj, Xnsiendo {X1, ., Xi} el atributo clave de larelación, se dice que el atributo Xj tienedependencia funcional completa respecto dela clave si toda la clave determina alatributo Xj pero ninguno de los atributos dela clave {X1, ., Xi} por separado (ni unsubconjunto de ellos) determina a XjSólo es necesario verificar la existencia dedependencia funcional completa cuando laclave está formada por dos o más atributos.Una clave formada por un único atributosiempre tiene dependencia funcionalrespecto a los demás atributos.

NORMALIZACIÓN2. NORMALIZACIÓN Y FORMAS NORMALES2.3. DEPENDENCIA FUNCIONAL COMPLETAEJEMPLO DE DEPENDENCIA FUNCIONAL COMPLETA En la siguiente tabla se muestran las horas trabajadas anualmente por unos empleados:Cód EmpleadoAñoHoras 1Para verificar si existe una dependencia funcional completa comprobamos lo siguiente:ooooEl atributo clave está formado por la combinación de dos o más atributos: Cod Empleado y Año.Por sí sólo, el atributo Cod Empleado no determina al atributo Horas Trabajadas.Por sí sólo, el atributo Año no determina al atributo Horas Trabajadas.Conjuntamente, Cod Empleado y Año sí determinan al atributo Horas TrabajadasCód EmpleadoHoras TrabajadasAñoHoras TrabajadasCód Empleado AñoHoras TrabajadasPor tanto, el atributo Horas Trabajadas tiene dependencia funcional completa respecto a la clave.

NORMALIZACIÓN2. NORMALIZACIÓN Y FORMAS NORMALES2.3. DEPENDENCIA FUNCIONAL COMPLETACONTRAEJEMPLO DE DEPENDENCIA FUNCIONAL COMPLETA En la siguiente tabla se muestran las horas trabajadas anualmente por unos empleados. Para generar unaanomalía, en la tabla se ha incluido la columna 'NIF':Cód EmpleadoAñoNIFHoras 4985201646468585T5985201246468585T341Para verificar si existe una dependencia funcional completa comprobamos lo siguiente:oooEl atributo clave está formado por la combinación de dos o más atributos: Cod Empleado y Año.Por sí sólo, el atributo Cod Empleado determina al atributo NIF. Esta dependencia parcial impideque haya dependencia funcional completaPor sí sólo, el atributo Año no determina al atributo NIF.Cód EmpleadoNIFAñoHoras TrabajadasPor tanto, no se cumplen las condiciones para establecer una dependencia funcional completa entre elatributo NIF y la clave.

NORMALIZACIÓN2. NORMALIZACIÓN Y FORMAS NORMALES2.4. DEPENDENCIA FUNCIONAL TRANSITIVADEPENDENCIAFUNCIONAL Si 'X', 'Y' y 'Z' son atributos de una relación, se diceTRANSITIVA que 'X' determina a 'Z' de manera transitiva a travésde 'Y', si la dependencia se establece indirectamentea través de un atributo intermedio 'Y', es decir: XZsi se cumple lo siguiente: XY YZ YXSólo es necesario verificar la existencia dedependencia funcional transitiva cuando larelación contiene más de un atributo noclave.Una relación con un único atributo no-clavenuncatienedependenciafuncionaltransitiva.

NORMALIZACIÓN2. NORMALIZACIÓN Y FORMAS NORMALES2.4. DEPENDENCIA FUNCIONAL TRANSITIVAEJEMPLO DE DEPENDENCIA FUNCIONAL TRANSITIVA En la siguiente tabla se muestra la población de distintas áreas postales (áreas geográficas delimitadas porun código postal) ContinentePaísZIP (C.P.)Habitantes 13430205250.000 13430005500.000 276995011.500 2831701372.527.600 37BN1 1DA26.980Para verificar si existe una dependencia funcional transitiva comprobamos lo siguiente:oooEl atributo ZIP (el código postal de una zona) determina al atributo País: ZIPEl atributo País determina al atributo Continente:PaísEl atributo País no determina al atributo ZIP:PaísPaísContinenteZIPEn estas condiciones se cumple la dependencia transitiva:ContinenteZIP

NORMALIZACIÓN2. NORMALIZACIÓN Y FORMAS NORMALES2.5. INCLUSIÓN DE LAS FORMAS NORMALES5FN4FNFNBC3FN No hay atributos clave que dependan funcionalmente de otros atributosno-clave, o lo que es lo mismo, no es posible intercambiar un atributocandidato por el atributo clave. No existen dependencias funcionales transitivas respecto a la clave, esdecir, no existe dependencia funcional entre atributos no-clave.2FN Cada atributo no-clave tiene dependencia funcional completa respecto dela totalidad de la clave.1FN Existe un atributo clave, no nulo y único, que identifica a cada tupla. No existen atributos multivaluados ni compuestos.

NORMALIZACIÓN3. PRIMERA FORMA NORMAL (1FN) Una relación se encuentra en Primera Forma Normal si se cumple lo siguiente:1FN No hay dos tuplas (filas) iguales, es decir, existe una claveúnica y no nula que identifica a cada tupla, formada porun atributo clave (o un conjunto de ellos). Cada atributo sólo puede tomar un único valor atómico(es decir, no hay atributos multivaluados ni atributoscompuestos). En caso de existir atributos multivaluados o compuestos, es necesario modificar la relación para que cadaatributo represente un valor atómico. La Primera Forma Normal es un requisito esencial para una relación: constituye la base de la integridadreferencial y compartimenta la información de una relación en elementos indivisibles.

NORMALIZACIÓN3. PRIMERA FORMA NORMAL (1FN)3.1. ELIMINACIÓN DE ATRIBUTOS MULTIVALUADOS La eliminación de atributos multivaluados puede realizarse siguiendo una de estas estrategias:ALTERNATIVA 1: SEGMENTAR EL ATRIBUTO MULTIVALUADOTabla con atributos multivaluados (Apellidos):Cód 01JetulioPencas Morcillo985CleofásTijerilla985GenaroTormo CansinoNormalizaciónCód laNULL985GenaroTormoCansino

NORMALIZACIÓN3. PRIMERA FORMA NORMAL (1FN)3.1. ELIMINACIÓN DE ATRIBUTOS MULTIVALUADOSALTERNATIVA 2: CREAR UNA NUEVA RELACIÓNTabla con atributos multivaluados (Actor):Cod Año2 Tablas en 1FN:ActorCod PeliPelículaAño1La amenazafantasma19991999Ewan McGregorLeam NeesonNatalie Portman1982Harrison FordSean Young2Blade Runner19823Avatar20092009Sigourney WeaverZoe SaldanaNormalizaciónCod PeliActor1Ewan McGregor1Leam Neeson1Natalie Portman2Harrison Ford2Sean Young3Sigourney Weaver3Zoe Saldana

NORMALIZACIÓN4. SEGUNDA FORMA NORMAL (2FN) Una relación se encuentra en Segunda Forma Normal si se cumple lo siguiente:2FN La relación está en 1FN. Cada atributo no-clave tiene dependencia funcionalcompleta de la clave. En caso de no existir dependencia funcional completa respecto a la clave (es decir, en caso de que existadependencia funcional parcial), es necesario modificar la relación, extrayendo los atributos condependencia parcial y el atributo del que dependen a una nueva relación, para obtener así un conjunto derelaciones en las que sólo hay dependencia funcional completa respecto a la clave La Segunda Forma Normal compartimenta la información impidiendo que una relación representeinformación de entidades o hechos distintos.

NORMALIZACIÓN4. SEGUNDA FORMA NORMAL (2FN)4.1. ELIMINACIÓN DE DEPENDENCIAS FUNCIONALES PARCIALES Si una relación presenta alguna dependencia funcional parcial de la clave, es necesario modificar larelación para extraer los atributos con dependencia parcial a una nueva relación:La relación está en 2FNExtraer a una nuevarelación el (los) atributo(s)dependiente(s) y elatributo clave del quedepende(n)¿La relación en 1FN tieneuna clave simple?Ambas relaciones están en2FN¿Alguno de los atributosque forman la clavedetermina por sí solo aalgún atributo no-clave?Todos los atributos de laclave determinanconjuntamente al atributono-claveLa relación está en 2FN

NORMALIZACIÓN4. SEGUNDA FORMA NORMAL (2FN)4.1. ELIMINACIÓN DE DEPENDENCIAS FUNCIONALES PARCIALESEJEMPLO DE RELACIÓN EN 2FN (DEPENDENCIA FUNCIONAL COMPLETA)Tabla 'Repuestos' en 2FN: La siguiente tabla contiene información sobre laspiezas de repuesto utilizadas en un servicio técnicode reparación de móviles. Cada pieza tiene unfabricante, identificado por un código único y cadafabricante identifica a sus piezas mediante unnúmero de pieza único para ese fabricante:Cód FabricanteCod PiezaDescripciónLG MP130056Pantalla capacitivaLG MP130057Pantalla resistivaSAM-MOB-PART0001-34-96Batería 3000mAhNOK-MOB-5657Módulo WiFiHUA.ES.PARTS57Cámara delanteraLa relación está en 2FN¿La relación en1FN tiene unaclave simple?¿Alguno de los atributosque forman la clavedetermina por sí solo aalgún atributo no-clave?Cód FabricanteDescripciónCód PiezaDescripciónExtraer a una nuevarelación el (los) atributo(s)dependiente(s) y elatributo clave del quedepende(n)Todos los atributos de laclave determinanconjuntamente al atributono-claveAmbas relaciones están en 2FNLa relación está en 2FNCód Fabricante Cód PiezaDescripción

NORMALIZACIÓN4. SEGUNDA FORMA NORMAL (2FN)4.1. ELIMINACIÓN DE DEPENDENCIAS FUNCIONALES PARCIALESEJEMPLO DE RELACIÓN CON DEPENDENCIA FUNCIONAL PARCIAL La siguiente tabla contiene información sobre las piezas de repuesto utilizadas en un servicio técnicode reparación de móviles. Cada pieza tiene un fabricante, identificado por un código único y cadafabricante identifica a sus piezas mediante un número de pieza único para ese fabricante. Además,para cada fabricante, se almacena una dirección de email para solicitar más repuestos:Tabla 'Repuestos' con dependencia funcional parcial:Cód FabricanteCod PiezaDescripciónEmail Solicitud RepuestosLG MP130056Pantalla capacitivalg mobile parts@lg.comLG MP130057Pantalla resistivalg mobile parts@lg.comSAM-MOB-PART0001-34-96Batería Módulo WiFiHUA.ES.PARTS57Cámara delanteranokia.lumia.parts@microsoft.comhuawei parts@huawei.com

NORMALIZACIÓN4. SEGUNDA FORMA NORMAL (2FN)4.1. ELIMINACIÓN DE DEPENDENCIAS FUNCIONALES PARCIALESEJEMPLO DE RELACIÓN CON DEPENDENCIA FUNCIONAL PARCIALTabla 'Repuestos' con dependencia funcional parcial:Cód FabricanteCod PiezaDescripciónEmail Solicitud RepuestosLG MP130056Pantalla capacitivalg mobile parts@lg.comLG MP130057Pantalla resistivalg mobile parts@lg.comSAM-MOB-PART0001-34-96Batería Módulo WiFiHUA.ES.PARTS57Cámara delanteranokia.lumia.parts@microsoft.comhuawei parts@huawei.comLa relación está en 2FN¿La relación en1FN tiene unaclave simple?¿Alguno de los atributosque forman la clavedetermina por sí solo aalgún atributo no-clave?Cód FabricanteExtraer a una nuevarelación el (los) atributo(s)dependiente(s) y elatributo clave del quedepende(n)Ambas relaciones están en 2FNTodos los atributos de laclave determinanconjuntamente al atributono-claveLa relación está en 2FNEmail Solicitud Repuestos

NORMALIZACIÓN4. SEGUNDA FORMA NORMAL (2FN)4.1. ELIMINACIÓN DE DEPENDENCIAS FUNCIONALES PARCIALESEJEMPLO DE RELACIÓN CON DEPENDENCIA FUNCIONAL PARCIAL Para eliminar la dependencia funcional parcial, se extrae a otra tabla el (los) atributo(s)dependiente(s) así como el atributo clave del cual dependen:Tabla 'Repuestos' con dependencia funcional parcial:Cód FabricanteCod PiezaDescripciónEmail Solicitud RepuestosLG MP130056Pantalla capacitivalg mobile parts@lg.comLG MP130057Pantalla resistivalg mobile parts@lg.comSAM-MOB-PART0001-34-96Batería Módulo WiFiHUA.ES.PARTS57Cámara delanteraTabla 'Repuestos' en uawei parts@huawei.comTabla 'Email Solicitudes' en 2FN:Cód FabricanteCod PiezaDescripciónCód FabricanteEmail Solicitud RepuestosLG MP130056Pantalla capacitivaLG MPlg mobile parts@lg.comLG MP130057Pantalla resistivaLG MPlg mobile parts@lg.comSAM-MOB-PART0001-34-96Batería NOK-MOB-5657Módulo S.PARTS57Cámara delanteraHUA.ES.PARTShuawei parts@huawei.com

NORMALIZACIÓN5. TERCERA FORMA NORMAL (3FN) Una relación se encuentra en Tercera Forma Normal si se cumple lo siguiente:3FN La relación está en 2FN. No existen dependencias funcionales transitivas, es decir,no existe dependencia funcional entre atributos no-clave. En caso de existir dependencia funcional transitiva (es decir, en caso de que exista dependencia funcionalentre atributos no-clave), es necesario modificar la relación, extrayendo los atributos no-clavedependientes y los atributos determinantes de los que dependen a una nueva relación, para obtener asíun conjunto de relaciones en las que no hay dependencia entre atributos no-clave. Una relación en Tercera Forma Normal generalmente está libre de anomalías de inserción, modificación yborrado.

NORMALIZACIÓN5. TERCERA FORMA NORMAL (3FN)5.1. ELIMINACIÓN DE DEPENDENCIAS FUNCIONALES TRANSITIVAS Si una relación presenta alguna dependencia funcional transitiva a través de la clave, es necesariomodificar la relación para extraer los atributos no-clave dependientes a una nueva relación:La relación está en 3FNExtraer a una nuevarelación el (los) atributo(s)dependiente(s) y elatributo del quedepende(n)¿La relación en 2FN tienemás de un atributo noclave?¿Alguno de los atributosno-clave determina a otroatributo no-clave?La relación está en 3FNAmbas relaciones están en3FN

NORMALIZACIÓN5. TERCERA FORMA NORMAL (3FN)5.1. ELIMINACIÓN DE DEPENDENCIAS FUNCIONALES TRANSITIVASEJEMPLO DE RELACIÓN CON DEPENDENCIA TRANSITIVA La siguiente tabla contiene información sobre los empleados de una empresa: nombre, apellidos y datos deldepartamento en el que trabajan. A los efectos de este ejemplo se considera que los apellidos y el teléfono son valoresatómicos:Tabla 'Empleados' en 2FN: Cód hamel PencasSIS01#125796JetulioPencas Cód EmpleadoNombre, Apellidos, Departamento, Tlf DptoDepartamentoTlf DptoDepartamentoCód EmpleadoTlf DptoCod EmpleadoTlf DptoEl atributo no-clave 'Departamento' determina al atributo no-clave 'Tlf Dpto' y no determina a la clave, 'Cód Empleado'.Tlf Dpto . Esta dependencia viola laEn esta situación se cumple una dependencia transitiva por la que Cod Empleado3FN, por lo que es necesario normalizar la relación.

NORMALIZACIÓN5. TERCERA FORMA NORMAL (3FN)5.1. ELIMINACIÓN DE DEPENDENCIAS FUNCIONALES TRANSITIVASEJEMPLO DE RELACIÓN CON DEPENDENCIA TRANSITIVATabla 'Empleados' en 2FN:Cód EmpleadoNombreApellidosDepartamentoTlf Dpto50001BalbinoBechamel PencasSIS01#125796JetulioPencas La relación está en 3FNExtraer a una nueva relaciónel (los) atributo(s)dependiente(s) y el atributodel que depende(n)¿La relación en 2FN tienemás de un atributo noclave?¿Alguno de los atributosno-clave determina a otroatributo no-clave?La relación está en 3FNLas nuevas relaciones están en3FN

NORMALIZACIÓN5. TERCERA FORMA NORMAL (3FN)5.1. ELIMINACIÓN DE DEPENDENCIAS FUNCIONALES TRANSITIVASEJEMPLO DE RELACIÓN CON DEPENDENCIA TRANSITIVATabla 'Empleados' en 2FN:Cód EmpleadoNombreApellidosDepartamentoTlf Dpto50001BalbinoBechamel PencasSIS01#125796JetulioPencas NormalizaciónTabla 'Empleados' en 3FN:Tabla 'Departamentos' en 3FN:Cód 01BalbinoBechamel PencasSIS01SIS01#125796JetulioPencas 2DES01.02#113Tlf Dpto

NORMALIZACIÓN6. FORMA NORMAL DE BOYCE-CODD (FNBC) Una relación se encuentra en Forma Normal de Boyce-Codd si se cumple lo siguiente:FNBC La relación está en 3FN. No existen claves compuestas formadas por atributos quedependan de atributos no-clave. Esto equivale a verificarque no existen claves candidatas que puedan serintercambiadas por la clave. En caso de que algún atributo clave dependa funcionalmente de un atributo no-clave, es necesariomodificar la relación, extrayendo el atributo no-clave y el atributo clave del que depende a una nuevarelación. Una relación en Forma Normal de Boyce-Codd está libre de anomalías de inserción, modificación yborrado y proporciona más compartimentación y consistencia que la 3FN. En la mayoría de casos, unatabla en 3FN también está en FNBC, aunque no se puede generalizar.

NORMALIZACIÓN6. FORMA NORMAL DE BOYCE-CODD (FNBC)6.1. ELIMINACIÓN DE DEPENDENCIAS FUNCIONALES DE ATRIBUTOS NO-CLAVE RESPECTO A ATRIBUTOS CLAVELa relación está en FNBC¿La relación en 3FNtiene una clavecompuesta(formada por másde un atributo)?La relación está en FNBC¿Alguno de losatributos no-clavedetermina a algúnatributo clave?Extraer a una nuevarelación el (los)atributo(s)dependiente(s) y elatributo del quedepende(n)Ambas relacionesestán en FNBC

NORMALIZACIÓN6. FORMA NORMAL DE BOYCE-CODD (FNBC)6.1. ELIMINACIÓN DE DEPENDENCIAS FUNCIONALES DE ATRIBUTOS NO-CLAVE RESPECTO A ATRIBUTOS CLAVEEJEMPLO DE RELACIÓN CON DEPENDENCIA DE UN ATRIBUTO CLAVE RESPECTO A UN ATRIBUTO NO-CLAVE La siguiente tabla contiene información sobre los proyectos en los que trabajan unos empleados y el servidor en el quese almacenan los informes de los proyectos. A los efectos de este ejemplo se considera que cada proyecto estáalmacenado en un único servidor y que un servidor almacena sólo un proyecto :Tabla 'Proyectos' en 3FN: Cód EmpleadoCod od Proyecto , o lo que es lo mismo, el atributo no-claveEn esta situación se cumple la dependencia Servidor'Servidor' se comporta como clave candidata y puede reemplazar al atributo clave ' Cod Proyecto'. Esta dependenciaviola la FNBC, por lo que es necesario normalizar la relación.

NORMALIZACIÓN6. FORMA NORMAL DE BOYCE-CODD (FNBC)6.1. ELIMINACIÓN DE DEPENDENCIAS FUNCIONALES DE ATRIBUTOS NO-CLAVE RESPECTO A ATRIBUTOS CLAVEEJEMPLO DE RELACIÓN CON DEPENDENCIA DE UN ATRIBUTO CLAVE RESPECTO A UN ATRIBUTO NO-CLAVETabla 'Proyectos' en 3FN:¿La relación en 3FNtiene una clavecompuesta(formada por másde un atributo)?Cód EmpleadoCod a relación está en FNBCLa relación está en FNBC¿Alguno de losatributos no-clavedetermina a algúnatributo clave?Extraer a una nuevarelación el (los)atributo(s)dependiente(s) y elatributo del quedepende(n)Ambas relacionesestán en FNBC

NORMALIZACIÓN6. FORMA NORMAL DE BOYCE-CODD (FNBC)6.1. ELIMINACIÓN DE DEPENDENCIAS FUNCIONALES DE ATRIBUTOS NO-CLAVE RESPECTO A ATRIBUTOS CLAVEEJEMPLO DE RELACIÓN CON DEPENDENCIA DE UN ATRIBUTO CLAVE RESPECTO A UN ATRIBUTO NO-CLAVETabla 'Proyectos' en 3FN:Cód EmpleadoCod abla 'AsignaciónEmpleados' en 3FN:NormalizaciónTabla 'AsignaciónServidores' en 3FN:Cód EmpleadoCod ProyectoServidorCod ETWORKNG.07192.168.0.134

NORMALIZACIÓN1FN Existe un atributo clave, único y no-nulo.Cada atributo sólo puede tomar un único valor, atómico. Nopuede haber atributos multivaluados ni compuestos.2FN 3FNLa relación está en 1FN.Cada atributo no-clave tiene dependencia funcionalcompleta de la clave. La relación está en 2FN.No existen dependencias funcionales entreatributos no-clave. La relación está en 3FN.En una clave compuesta, no hay atributos claveque puedan ser intercambiados por un atributoclave candidato.NORMALIZACIÓNFNBC4FN5FN

NORMALIZACIÓN7. DENORMALIZACIÓNLa normalización del modelorelacional es un proceso derefinamiento que mejora laspropiedades formales deldiseño.Habitualmente, una base dedatos se mantiene en 3FN oFNBC para garantizar unequilibrio entre el diseñocorrecto y el rendimiento delas consultas.Sin embargo, conformeaumenta la forma normalalcanzada para una relación,aumenta la compartimentacióny, por tanto, el número derelaciones creadas.Para mejorar el rendimientopuede optarse por reducir elgrado de normalización deldiseño, introduciendo ciertaredundancia controlada, peromanteniendo la integridad yconsistencia.Un número elevado de tablasdificulta la comprensión delesquema general de la base dedatos. Para evitar esteproblema, pueden utilizarseVistas, como veremos en lasiguiente unidad, que aíslan alas aplicaciones y a los usuariosde la complejidad del diseño.Las vistas abstraen lacomplejidad del diseño peroaún así, cuando se realizanconsultas para acceder a lainformación almacenada, elrendimiento de la consultadecrece al aumentar el númerode tablas implicadas en laconsulta.Esta reducción en el grado denormalización recibe elnombre de 'denormalización'.

diseño de una base de datos. Para llevar una base de datos a una forma normal hay que imponer una serie de restricciones a los atributos del modelo relacional. Existen 6 formas normales. Conforme se alcanzan formas normales superiores, el diseño mejora conteniendo la redundancia, compartimentando la información y eliminando anomalías.