NORMALIZACION DE BASES DE DATOS RELACIONALES El proceso de normalizacién fue introducido por Codd en el ao 1974. Busca encontrar errores en el diselo de un esquema relacional debido a la presencia de redundancias que pueden originar anomalias de operaciones. Para eliminar los problemas, la normalizacién divide una relacion en dos (© més relaciones que garanticen la eliminacion de anomalias, a costa de crear redundancia SOLO a nivel de claves. La teoria de la normalizacién tiene como fundamento el concepto de formas normales. Una relacién esté en una determinada forma normal si satisface un conjunto de restricciones. Codd introdujo tres formas normales como solucién a las anomalias de operaciones: PRIMERA FORMA NORMAL (1FN), SEGUNDA FORMA NORMAL(2FN) y TERCERA FORMA NORMAL(3FN). Mas adelante Boyce y Codd introducjeron una forma normal mas restrictiva a la que llamaron FORMA NORMAL DE BOYCE Y CODD (BCNF). Posteriomente se ha extendido la teoria de la normalizacién para incluir otros tipos de dependencias funcionales y se definieron la CUARTA FORMA NORMAL (4FN), QUINTA FORMA NORMAL(SF) y otras formas normales. Se estudiarén las tres primeras formas normales y le forma normal de Boyce y Codd, porque son realmente las més utilizadas. Cuanto mas alta sea la forma normal en le que se encuentran los esquemas de relacién, menores, serdn los problemas que aparecerén en el mantenimiento de la base de datos. Para avanzar de una forma normal a otra, deben verificarse las restricciones de la actual y de le nueva forma normal. Una de las herramientas més utilizadas para alcanzar una nueva forma normal es la descomposicién que debe tener las siguientes caracteristicas: * Debe realizarse sin pérdida # Deben mantenerse las dependencias funcionales "Se debe evitar o reducir hasta donde sea posible la reduncancia, La definicion original de las formas normales tomaba en cuenta SOLO la clave primaria de una relacién para efectuar la normalizacién y la verificacién de cumplimiento de formas normales. Posteriormente, se cambié toda la teoria @ una definicién basada sobre todas las claves candidates de una relacién. Esto se debe al hecho singular de que durante la vida de una base de datos puede ser cambiada la clave primaria original por otra clave candidata y por lo tanto, sila normalizacién se efectué considerando sélo la clave primaria puede suceder que una base de datos inicialmente normalizada pudiese aparecer como desnormalizede al cambiar la definicién de la clave primaria, Pagina a deDEPENDENCIAS FUNCIONALES Una dependencia funcional es una conexidn entre uno o més atributos. Se dice que un conjunto de atributos [Y) depende funcionalmente de otro conjunto de atributos (X) si para cada valor de X hay un Uinico valor posible para Y. Simbélicamente se denota por XY. Al conjunto X del que depende funcionalmente el conjunto Y se le llama determinante. Al conjunto Y se le llama implicado, EMP CEDULA, NOMBRE ‘CIUDAD 123433545 | BernardoGémez | Call 454656554 | RosarioDuque | Bogotd 565656754 | NubiaCastro Neva 787978789 | Vanesa alas Mocoa En la relacién TRABAJADOR, el campo CEDULA es la clave primaria, por lo tanto, acta como determinante. Como las dependencias funcionales se establecen con los otros campos que no son clave (implicados), habria dos opciones para establecer dependencias: 1. Cedula->nombre _£! NOMBRE depende funcionalmente de la cédula porque para un numero concreto de cedula sdlo hay un nombre posible. 2. Cedula->ciudad La CIUDAD NO depende funcionalmente de la cédula porque para un mismo numero de cédula puede haber mds de una ciudad. De acuerdo con lo anterior, en la relacion TRABAJADOR solo existe una dependencia funcional: Cedula > nombre to Determinante — implicado La anterior dependencia se puede leer de las siguientes formas: nombre es funcionalmente dependiente de cédula o cédula determina a nombre ‘TIPOS DE DEPENDENCIAS FUNCIONALES: Dependencia funcional completa Un conjunto de atributos (Y) tiene una dependencia funcional completa sobre otro conjunto de atributos (X) si Y tiene dependencia funcional de X y ademas no se puede obtener de X un conjunto de atributos més pequefio que consiga una dependencia funcional de Y. Ejempl En la relacién CALIFICACIONES la clave primaria esta compuesta ‘God estudiante | Cod azignature | nota_| por los atributos Cod_estudiante y Cod_asignatura, 10212 2 46 Se puede establecer la dependencia funcional: 10908 2 a7 Codigo_estudiante,codigo_asignatura => nota 28989 10 27 porque la nota depende de ambos atributos de clave primaria. 10989 rT 32) No hay dependencia parcial con alguno de los comonentes de la clave primaria, Pagina? de7Dependencia funcional elemental Se produce cuando X e Y forman una dependencia funcional completa y ademés Y es un Unico atributo. Cedula—> nombre Dependencia funcional transitiva Se produce cuando tenemos tras conjuntos de atributes X, Y y Z. Y depende funcionalmente de X (XY), Z depende funcionalmente de Y (V2). Ademés X no depende funcionalmente de ¥, Entonces ocurre que X produce una dependencia funcional transitive sobre Z. Ejemple 1: Numero_clase > codigo_tutor Codigo_tutor->Codigo_departamento Entonces: Numero_clase -—-codigo_departamento El cédigo del departamento depende transitivamente del cédigo de la clase. NORMALIZACION - Formas Normales PRIMERA FORMA NORMAL(1FN) Una tabla se encuenta en primera forma normal cuando cumple con las siguientes condiciones: 1. Los valores de los atributos deben ser atémicos". 2. Dos filas no deben ser idénticas -una tabla no debe contener filas repetidas; si existen deben eliminarse asegurdndose de que cade fila defina una sola entidad. Para lograrlo hay que asegurarse de que cada registro(fila) esté identificado a través de una clave primaria-. 3. No hay valores nulos 4, Se impide que un atributo de una fila tome mas de un valor -evitar atributos multivalorados~ Esta forma normal elimina los valores repetidos dentro de una 8D EMPL Ena relaciin EMPLEADOS, se puede ver que el romire ——[ouesio | slaves atributo emails contiene més de un valor, por eww — [emer [oot —Tpretnz auusis__[ vies [ ete —{ tent {rinses | 1, quo viola TFN La slucin os crear una nueva ‘nts — nes eras? 9) treats) tabla con ls atibutos email dentificacon ce a — omnes ee ad a jessietaren laentihadon norte reese tere | | Mentiecon | emai 23saa333 | anaveles | Cantacor_|s800”) [28300333 | scles@aonam 354sa543 | Sonavincor—[Sterar [3000 [35e34sas | sicoeeanncom 4775283 | tnestontedine | Vendedor | 1200 | |€4775243 | emesinataon.com 45450524 [my Forero’ [Jefe sres | 6000) | asasasaa | fincere@aoncom a5asasza | forerna4ahatmal Clave primaria — identificacién clave primaria — identificacion, emails. * Ln dominio ae animico cla alemeoe del domino econstonon nade iabvitiles Par giomplo el conte ds las enero a daniniaatimiea Pagina 3 de7SEGUNDA FORMA NORMAL (2FN) Una tabla se encuenta en segunda forma normal cuando cumple con las siguientes condiciones - Estd en IFN + Cada atributo que no sea clave (no-primo), es totalmente dependiente de toda clave(primo). + Toda clave principal debe hacer dependientes al resto de los atributos. Si hay atributos que dependen solo de parte de la clave, entonces esa parte de la clave y esos, atributos formarén otra tabla, EJEMPLO 1: En Clave primaria: coo COD_CURSO | NOWBRE APELLIDD NOTA, codigo, cod_curso. pas [2 Garoina | Rojas &7 s7e16ss4 | 22 Menkes [Gomer 78 Dependencias funcionales: 3265423 Camnlo Muir 45 | codigo,cod_curso > nota 33535466 | 23 Dez fonils sg Codigo» nombre, apellido gos00899 | 22 lucia [Casto 18 La tabla estudiantes no esté en 2FN porque no todos los atributos no-primos dependen de la clave primaria, En la relacién ESTUDIANTES, los atributos no-primos nombre y apellide dependen parcialmente de la clave codigo,cod_curso proque la dependencia funcional Codigo > nombre, apellido es parcial. Por lo tanto ESTUDIANTES no estd en 2FN. Para que la relacién ESTUDIANTES alcance la 2FN se debe descomponer considerando que: + Launica clave de estudiantes es codigo,cod_curso = Los atributos no-primos de estudiantes son nombre, apellido y nota + Para el atributo no-primo Nota, hay una dpependencia total con la clave codigo, cod_curso. = Para los atributos no-primos nombre, apellido existen dependencias funcionales parciales de codigo,cod_curso lo que obliga @ descomponer ESTUDIANTES en dos relaciones: ESTUDIANTE = {codigo, nombre, apellido} C0060 | €O0_CURSD | NOMBRE | APELUDO | NOTA. con dependencias funcionales a — Cerca [naps [7 ‘s67essa 2 Monica | Gomed | 78 codigo — nombre inne [|i oar — codigo—apelido a na ASISTENCIA_CURSOS = (codigo, Cod curso, nota} j Con dependencias funcionales: codigo, cod curso.— nota 00 | NOMBHE APD) | COO CO0CRD NOTA 29005 | Cain | fos) (29006) at | 7 tnens3 | incr | Gone ae Snnpwst [cis or as assists | Dees | ton | [sass ay se senate | cn | ove | (stems | at Pagina a de7EJEMPLO 2; {ONI, ID_PROYECTO} —+HORAS_TRABAIO Porque con el DNI de un empleado y el ID de un proyecto sabemos cuntas horas de trabajo por semana trebaja un empleado en dicho proyecto. Es completamente dependiente dado que ni DNI-+HORAS_TRABAIO ni ID_PROYECTO —sHORAS_TRABAIO mantienen la dependencia por separado. Sin embargo {ONI, ID_PROYECTO} —+NOMBRE_EMPLEADO es parcialmente dependiente dado que ON| —+NOMBRE_EMPLEADO mantiene la dependencia. ‘TERCERA FORMA NORMAL (3FN) Una relacion esté en tercera forma normal si cumple que esta en segunda forma normal y ningiin atributo no-primo depende transitivamente de alguna clave. EJEMPLO Considérese la relacién ESTUDIANTE con clave primaria CODIGO y sus demas atributos : ESTUDIANTE = (codigo, nombre, codigo_carrera, descripcion_carrera) nombre | Codige_carrera | Deseripcion_carrera 10219 | Ana 2 Ingenieria alimentos 30982 | juan a Ingenieria industrial 37687 | _aeto 7 Ingenieria sistemas 21234 [Diana 2 Ingenieria industrial Dependencias funcionales: a) codigo» nombre b) codigo — codigo_carrera ¢) codigo sdescripcion_carrera Primero hay que verificar si ESTUDIANTE se encuentra en 2FN: Los atributos no-primos de estudiante son: nombre, codigo_carrera,descripcion_carrera, La dnica clave de estudiante es codigo y existen dependencias funcioneles 2, b y c que son dependencias totales porque la clave primaria esté compuesta por un solo abtributo. - no puede quitarse ningiin atributo determinante-. En este caso estudiante esté en 2FN. Ahora se verifica si ESTUDIANTE esté en 3FN: Aparte de las dependencias funcionales a,b y c, se puede definir otra dependencia funcional que no involucra la clave primaria: 4) codigo_carrera —+descripcion_carrera Tomando en cuenta las dependencias funcionales by d, y considerando que NO se da la dependencia funcional codigo_carrera —> codigo, se puede decir que descripcion_carrera_depende transitivamente de codigo a través de codigo_carrera, por lo que ESTUDIANTE no estd en 3EN. codigo — codigo_carrera codigo_carrera —sdescripcion_carrera por lo tante. codigo ~—+descripcion_carrera Para que ESTUDIANTES esté en 3FN es necesario descomponerle de a siguiente manera Paginas de7ESTUDIANTE = {codigo, nombre, codigo carrera} Con dependencias funcionales sodige nombre | Codigo_carrera codigo —snombre 10219 | Ana 2 codigo —scodigo_carrer 0992 | Juan 2 es igo 17687 Beto. a CARRERA = {codigo_carrera,descripcion_carrera} Con dependencias funconales [ogo carrera | Descripcion arr codigo_carrera —edescripelon_¢ 2 Ingenieria alimentos 33 ingeneris indus ul Ingenieria sistemas FORMA NORMAL DE BOYCE Y CODD (BCNF Una relacién esté en BCNF si esta en 3FN y todo determinante es una clave candidata. EJEMPLO 1: Considere la relacién PACIENTE con los atributos: PACIENTE = {num_histeria, nombre, direccién, cédula} Con las dependencias funcionales: Num_historia nombre, direccién, cedula Cédula—snum_historia, nombre, é Encontramos que existen dos claves candidates (num_historia, cédula) y dos atributos no-primos (nombre, direccién). PACIENTE esté en FNBC porque los determinantes de todas sus dependencies funcionales (num_historia, cedula) son claves candidatas. EJEMPLO 2: Considérese la relacién TUTORIAS = {cédigo-tutoria, nombre-asignatura tutor} Con dependencias funcionales: cédigo_tutoria,nombre-asignatura —stutor tutor — nombre-asignatura, TUTORIAS esté en tercera forma normal (no hay dependencias transitivas), pero no esté en forma Boyce y Codd, porque el determinante tutor no es clave candidata. La redundancia de la asignatura se puede resolver descamponiendo la relacién: TUTORIAS = {codigo tutoria, tutor} ASIGNATURAS_TUTOR = { tutor jnombre-asignature } Algunas relaciones no se pueden llevar @ al BCNF manteniendo las dependencias funcionales. Como regla general, se debe tratar siempre la BCNF sies posible, es preferible preservar las dependencias funcionales y dejar una relacién en 3FN. Plgina 6 de7REFERENCIAS BIBLIOGRAFICAS. betpe://wwyr.u-cursos cl/diplomados/?000/0/0GINTELNEG/1/material docente/obieto/?18445 http: utplonline.edu ec/cursos/diretoria/apoio 7059 16206/1FN. pat http /unwejorgesancher.net/bd/bdrelacional oat http /es wikipedia org/wiki/NormalzaciC3%83n de bases de datos Pagina 7 de7