PARTE IV Teoria y metodologia del disefio de bases de datosCAPITULO 14 Dependencias funcionales y normalizaci6n en bases de datos relacionales Del Capitulo 7 al 10, presentamos varios aspectos del modelo relacional. Cada esquema de rela- cidn consiste en varios atributos y el esquema de base de datos relacional consta de varios esque- mas de relacién. Hasta aqui, hemos supuesto que los atributos se agrupan para formar un esquema de relacién empleando el sentido comiin del diseftador de bases de datos o estableciendo una trans- formaci6n de un esquema especificado en el modelo entidad-relacién (ER) o en el modelo entidad relacién extendido (ERE) (0 algin otro modelo de datos conceptual similar) en un esquema rela- cional. El modelo ERE hace que el diseftador identifique tipos de entidad y tipos de relacién y sus atributos respectivos, lo que da lugar a una agrupacién natural y 16gica de los atributos en relacio- nes cuando se siguen los procedimientos de transformacién que vimos en las Secciones 9.1 y 9.2. Sin embargo, atin es preciso una medida formal de por qué una agrupacién de atributos para for- mar un esquema de relacién puede ser mejor que otra. Hasta ahora, en nuestro examen del disefio conceptual de los Capitulos 3 y 4 y su transformacién al modelo relacional en el Capitulo 9, no hemos desarrollado ninguna medida de lo apropiado del disefio 0 de su calidad que no fuera la mera intuici6n del disefiador. En este capitulo, estudiaremos parte de la teoria que se ha desarrollado para intentar elegir «buenos» esquemas de relaci6n, es decir, para medir formalmente las razones por las que una agru- pacién de atributos, en esquemas de relaciGn, es mejor que otra. Hay dos niveles en los que pode- mos evaluar la «bondad» de los esquemas de relaci6n. El primero es el nivel légieo (0 concep- tual), que se refiere a la manera en que los usuarios interpretan Ios esquemas de relacién y el significado de sus atributos. Contar con buenos esquemas de relacién en este nivel ayuda a los usuarios a comprendet con claridad el significado de los datos en las relaciones, y por lo tanto a formular sus consultas correctamente. El segundo nivel es el nivel de implementacién (0 de alma- cenamiento), que se refiere a cémo se almacenan y actualizan las tuplas de una relaciGn de base. Este nivel sdlo se aplica a los esquemas de relaciones de base (que se almacenaran fisicamente como ficheros) mientras que en el nivel I6gico nos interesan los esquemas tanto de las relaciones base como de las vistas (relaciones virtuales). La teoria para el disefio de bases de datos relacione les expuesta en este capitulo vale sobre todo para las relaciones de base, aunque algunos criterios de idoneidad también se aplican a las vistas, como veremos en la Seccién 14.1.440 Fundamentos de sistemas de bases de datos Ademés, como sucede con cualquier problema de disefio, el disefio de bases de datos puede realizarse mediante dos enfoques: (1) ascendente 0 (2) descendente. Una metodologfa de disefio ascendente consideraria las relaciones basicas entre atributos individuales como punto de partida, y las usarfa para crear relaciones. Aparte del modelo relacional binario,? este enfoque no se emplea mucho en la practica y tiene el problema de reunir un gran ntimero de relaciones de atributos bina- tios como punto de partida. Este enfoque también recibe el nombre de disefio por sintesis. Por el contrario, una metodologia de disefio descendente comenzarfa con un niimero de agrupaciones de atributos en relaciones que ya se han obtenido del disefio conceptual y de las actividades de trans- formacién. Después, se aplicaria el disefio por andlisis a las relaciones individual y colectiva- mente, dando lugar a una mayor descomposicién hasta que se satisfacen todas las propiedades de- seadas. La teorfa descrita en este capitulo es aplicable tanto a enfoques ascendentes como a descenden- tes, pero resulta més préctica cuando se aplica al enfoque descendente. Comenzamos en la Seccién 14.1 con un andlisis informal de algunos criterios para distinguir los esquemas de relacién buenos y malos. Luego, en la Seccién 14.2, definiremos el concepto de dependencia funcional, que es la Principal herramienta para medir formalmente la idoneidad de las agrupaciones de atributos en los esquemas de relacién. También estudiaremos y analizaremos las propiedades de las dependencias funcionales. En la Seccién 14.3, mostraremos cémo usay las dependencias funcionales para agrupar atributos en esquemas de relacién que estén en una forma normal. Un esquema de relacién esta en una forma normal cuando posee ciertas caracteristicas deseables. El proceso de normalizacién con- siste en analizar las relaciones para satisfacer una serie de requisitos cada vez més estrictos que dan lugar a unos agrupamientos que van siendo cada vez mejores, o a formas normales superiores. Mostramos la forma en la que se pueden emplear las dependencias funcionales, identificadas por el disefiador de bases de datos, para analizar una relacién con una clave primaria designada para de- terminar de qué forma normal se trata y cémo deberia descomponerse atin més para alcanzar la siguiente forma normal superior. En la Seccin 14.4, estableceremos definiciones més generales de algunas formas normales que no-requieren un andlisis y normalizacién paso por paso. El Capitulo 15 continia el desarrollo de la teoria relativa al diseiio de buenos esquemas relacio- nales. Mientras que en el Capitulo 14 nos centraremos en las formas normales para esquemas de una sola relacién, en el Capitulo 15 estudiaremos las medidas de idoneidad para cualquier conjunto de esquemas de relaci6n que globalmente constituya un esquema de base de datos relacional. Es- Pecificaremos dos de esas propiedades (la propiedad de reuni6n no aditiva —sin pérdidas— y la propiedad de conservacién de las dependencias ) y analizaremos algoritmos para disefiar bases de datos relacionales a partir de las dependencias funcionales, las formas normales y las propiedades que acabamos de mencionar. En el Capftulo 15, definiremos también otros tipos de gependencias y formas normales avanzadas que mejoran atin mas las propiedades de los esquemas de relacién. El lector que solo busque una explicaci6n informal sobre la normalizaci6n puede pasar por alto las Secciones 14.2.3, 14.2.4, y 14.5. 14.1. Pautas informales de disefio para los esquemas de relacion En esta seccién, analizaremos cuatro medidas informales de calidad para el disefio de esquemas de relacién: * Por ejemplo, la metodologia NIAM; véase Verheijen y VanBekkum (1982).Dependencias funcionales y normalizacién en bases de datos relacionales 441 Semintica de los atributos. Reduccién de los valores redundantes en las tuplas. Reduccién de los valores nulos en las tuplas. Eliminaci6n de la posibilidad de generacién de tuplas espurias. Estas medidas no siempre son independientes entre si, como veremos. 14.1.1. Semantica de los atributos de relacién Siempre que agrupemos atributos para formar un esquema de relacién, supondremos que hay un cierto significado asociado a los atributos. En el Capitulo 7 vimos cémo cada relacién puede inter- pretarse como un conjunto de hechos 0 enunciados. Este significado, o semantica, especifica como se han de interpretar los valores de los atributos almacenados en una tupla de la relacién; dicho de otro modo, qué relaci6n hay entre los valores de los atributos de una tupla. Si el diseiio conceptual se realiza cuidadosamente, seguido de una transformaci6n en relaciones, se habrfa tenido en cuenta la mayor parte de la seméntica y el disefio resultante deberfa tener un significado claro. En general, cuanto més fécil sea explicar la seméntica de la relaci6n, mejor seré el disefio del esquema correspondiente. Para ilustrar esto, consideremos la Figura 14.1, que es una versi6n sim- plificada del esquema de base de datos relacional EMPRESA de la Figura 7.5, y la Figura 14.2, que representa un ejemplo de las pobladas relaciones de ese esquema. El significado del esquema de _EMPLEADO- de. vexeres | FECHA.NCTO' | _DIRECCION NUMEROD op. DEPARTAMENTO. ale, NomareD | __NUMEROD NSS_JEFED ap LOCALIZACIONES_DEPT ce. NUMEROD ____|_LOCALIZACIOND os ap. PROYECTO de NomBREP | _ NUMERO! LOCALIZACIONP NUMD_ ap. ‘TRABAJA_EN den cee. nss_|numenop [Horas | ——_ ap. 14.1. Versién simplificada del esquema de la base de datos relacional eupness.442 Fundamentos de sistemas de bases de datos EMPLEADO NOMBREE Nss FECHA.NCTO| — DIRECCION NUMEROD ‘Smith John B. 123456789 09-01-1965 731 Fondren Houston. TX 5 Wong Franktin T, 393445555 (08-12-1955 638 Voss,Houston, TX 5 Zelaya,Alica J. 99988777 19-07-1968 3821 Castle, Spring. TX 4 Wallace Jennifer S. 987654921 20-06-1941 291 BerryBelare, 7X 4 NarayanRemeshK. 666884444 15-09-1962 975 Fire Oak Humble, TX 5 Engish,Joyos A, 459453453, 31-07-1972 5631 Rice,Houston,TX 5 Jabbar/Ahmad V, 1987387987 29-03-1969 980 Dallas, Houston, TX 4 Borg.James E. 288665555 10-11-1937 450 Stone Houston,TX 1 LOCALIZACIONES_DEP DEPARTAMENTO. 7 NUMEROD _|LOCALIZACIOND NOMBRED | NUMEROD | DMGRSSN ——_] FOP | OMGRSSN | 1 Houston Investigacién 5 330445555. 4 Staford Administracion 4 987654321 5 Bette Direocion 1 ‘888665555 5 ‘Sugariand 5 Houston TRAB) AIRE PROYECTO iss ROP .| H¢ Me nel ORAS INOMBREP | NUMEROP | LOCALIZACIONP] NUMD. 123466 1 325 irae 2 fa Productox 1 Bolare 3 pesaedaei| A °% ProductoY 2 ‘Sugartand 5 oe 3 a Produc 3 Houston 5 rena 3 a Conputerzactin 10 Staford 4 333445555 2 400 Reorganizacién 20 ‘Houston 1 oes A faa Nupvaspresiacone 20 Staford ‘ sa446555 10 100 seas 2» 100 909887777 ” 300 990887777 10 100 967987967 10 350 997967987 20 50 997654321 2 209 987658921 2 150 899665555 2 rio Figura 14.2. Ejemplos de relaciones para el esquema de la Figura 14.1. relaci6n EMPLEADO es bastante sencillo: cada tupla representa a un empleado, con los valores para su nombre (NOMBREE), ntimero de seguridad social (NSS), fecha de nacimiento (FECHA_NCTO) y do- micilio (DIRECCION), y para el ntimero de departamento al que pertenece (NUMEROD). El attibuto NUMEROD es una clave externa que representa una relacién implicita entre EMPLEADO y DEPARTAMEN- To. La semAntica de los esquemas DEPARTAMENTO y PROYECTO también es evidente; cada tupla DE- PARTAMENTO representa una entidad departamento, y cada tupla PROYECTO representa una entidad Proyecto. El atributo NSS_JEFE de DEPARTAMENTO relaciona un departamento con el empleado que es su jefe y NUMD de PROYECTO relaciona un proyecto con el departamento que lo controla; ambos son atributos de clave externa. La seméntica de los otros dos esquemas de relacién de la Figura 14.1 es un poco més compleja. Cada tupla de LOCALIZACIONES_DEPT contiene un mimero de departamento (NUMEROD) y una de las ubicaciones del departamento (LOCALIZACIOND). Cada tupla de TRABAJA_EN contiene el némero deDependencias funcionales y normalizaci6n en bases de datos relacionales 443 seguridad social de un empleado (NSS), el nimero de uno de los proyectos en los que ese empleado trabaja (NUMEROP) y el mimero de horas por semana que el empleado trabaja en dicho proyecto (HoRAS). No obstante, ambos esquemas tienen un significado bien definido, sin ambigiiedad. El es- quema LOCALIZACIONES_DEPT representa un atributo multivaluado de DEPARTAMENTO, en tanto que TRABAJA_EN representa una relaciGn M:N entre EMPLEADO y PROYECTO. Asf pues, todos los esque- mas de relacién de la Figura 14.1 pueden considerarse buenos en lo tocante a la claridad de su seméntica. Podemos enunciar la siguiente pauta para el disefio de un esquema de relacién. PAUTA 1: disefie un esquema de relacién de modo que sea fécil explicar su significado. No com- bine atributos de varios tipos de entidad ni tipos de relacién en una tinica relaciGn. Intuitivamente, si un esquema de relacién corresponde a un tipo de entidad o a un tipo de relacién, el significado tiende a ser claro. En caso contrario, la relacién tiende a ser una mezcla de miltiples entidades y relaciones y, por lo tanto, sera semAnticamente confusa. Los esquemas de relacién de las Figuras 14.3(a) y (6) también tienen seméntica clara. (Por aho- ra, el lector deberé hacer caso omiso de las Iineas que estén debajo de las relaciones, pues servirdn para ilustrar la notacién de dependencias funcionales en la Seccién 14.2.) Una tupla del esquema de relacién EMP_DEPT de la Figura 14.3(a) representa a un solo empleado pero contiene informa- cién adicional; ésta es el nombre (NOMBRED) del departamento al que pertenece el empleado y el mimero de la seguridad social (NSS_JEFED) del jefe del departamento. En el caso de la relacién eup_pROY de la Figura 14.3(b), cada tupla relaciona un empleado con un proyecto pero también incluye el nombre del empleado (NOMBREE), el nombre del proyecto (NOMBREP) y la ubicacién del proyecto (LOCALIZACIONP). Aunque no hay nada incorrecto en estas relaciones desde el punto de vista l6gico, se las considera disefios deficientes porque violan la pauta 1 al mezclar atributos de entidades distintas del mundo real, EMP-DEPT mezcla atributos de empleados y departamentos y ENP_PROY mezcla atributos de empleados y proyectos. Pueden servir como vistas, pero provocan problemas cuando se usan como relaciones de base, como veremos en la siguiente seccién. 14.1.2. Informacion redundante en las tuplas y anomalias de actualizacién Uno de los objetivos en el disefio de esquemas es minimizar el espacio de almacenamiento que ocupan las relaciones de base (ficheros). La agrupacién de atributos en esquemas de relacin tiene un efecto significativo sobre el espacio de almacenamiento. Por ejemplo, basta con comparar el espacio utilizado por las dos relaciones base EMPLEADO y DEPARTAMENTO de la Figura 14.2 con el espacio de la relacién base EMP_DEPT de la Figura 14.4, que es el resultado de aplicar la operacién de reunién natural a EMPLEADO y DEPARTAMENTO. En EMP_DEPT los valores de los atributos pertene- cientes a un departamento en particular (NUMEROD, NOMBRED, NSS_JEFED) se repiten por cada em- pleado que trabaja para ese departamento. En cambio, la informacién de cada departamento apa- rece s6lo una vez en la relaci6n DEPARTAMENTO de la Figura 14,2. Sdlo el ntimero del departamento (NUMEROD) se repite en la relacién EMPLEADO para cada empleado que pertenece al departamento. Podemos hacer comentarios similares respecto a la relacién EMP_PROY (Figura 14.4) que hace cre- cer la relacién TRABAJA_EN con atributos adicionales de EMPLEADO y PROYECTO. Otro problema grave que surge al emplear las relaciones de la Figura 14.4 como relaciones base es el de las anomalias de actualizacién. Estas pueden clasificarse en anomalfas de inserci6n, anomalias de eliminacién y anomalfas de modificaci6n.” 2 Codd (19724) la Secci6n 14.3 ntificé estas anomalfas para justificar Ia necesidad de normalizar estas relaciones, como veremos en,444 Fundamentos de sistemas de bases de datos f@ ® EMP_DEPT NOMBREE| NSS | FECHA NCTO | DIRECCION| NUMEROD | NOMBRED | NSS_JEFED EMP_PROY Nss_|_NUMEROP | HORAS |NOMBREE|NOMBREP LOCALIZACIONP | oF 5 Fs om ___} [Sistas eae encomnoces |eoeoa ae) Figura 14.3. Dos esquemas de relacién y sus dependencias funcionales. Los dos sufren anomalias de actualizacién. (a) Esquema de relacién eup.vePr. (b) Esquema de relacién eup_prov. EMP_DEPT NOMBREE Nss FECHA.NCTO} DIRECCION | NUMEROD | NoMBRED | NSS_JEFED Smith John B 23456789 08-01-1965 731 FondrenHoustonTX 5 Investigacion Sa3445555 WongFrankinT. 333445555 08-12-1955 638 Voss Houston, TX 5 Investigacion» 333445555 Zelaya, Aca J. 990887777 19-07-1968. 3821 Castle, Spring, TX 4 ‘Aominsacon 987654321 WatacelenniterS. 987654321 2006-4981 291 Beny.Bolare.TX 4 ‘Adminisacén 967654321 Narayan Ramesh K. 666884444 15.09.1962 975 Freak Humble TX 5 Investigacion 33344555. EngishJoyee A. 453453453. 31-07-1972 5631 ce Houston, TX 5 Investgacién 833445555, abbar Ahmad V. 9879879867 28.03-1969 980 Dalles Houston, TX 4 ‘Admiisracion 987654321 Borg.James E. (888665555 10-11-1987 450 Stone,Houston. TX 1 ‘Direooi6n, ‘BBB6ES555 EMP_PROY Nss_|NUMEROP] HORAS | NOMBREE — | NOMBREP | LOCALIZACIONP vemsers9 1 325 SmithylohnB ProductoX Botaira 1234667892 75 Smithdohn B ProducioY Sugatiand eceseess 8 400 Narayan.Ramesh K. ProductoZ Houston 459450453 t 20.0 EngishJoyos A ProcucoX Betaire 4504554532 200 EngichJoyceA. Producto ‘Sugarland SeOS555 2 109 Wong Frankin 7, Producto ‘Sugadiand BeOS555 100 Wong FrankinT. — Productoz Houston 350445555 10 100 Wong FrankinT. — Computerzacién Stafford 333448555 20 100 Wong.Frankin. eorganizacén Houston 900887777 30 900 ZelayaAbciaJ.” ——-Nuevasprestacione Stafford 990887777 10 100. _ZelayaAlcaJ. —s Staford 987987987 10 350 JabbarAhmadV. Computerizaciin Stafford 987987887 30 50 Jabbar Ahmad V. Computerzacién Stafford 957654221 30 200 Walace.lenniforS. Nuevasprestacione Stafford se7estse1 20 150 WalaceJenniferS, Houston BeB66E555 20 ull Borguames,”—Nuevasprestacione Houston, Figura 14.4. Relaciones ejemplo para los esquemas de la Figura 14.3 que resultan de aplicar una REUNION NATURAL a las relaciones de la Figura 14.2. Estas pueden almacenarse como relaciones de base para un mejor rendimiento.Dependencias funcionales y normalizacién en bases de datos relacionales 445 Anomalfas de insercién. Estas pueden diferenciarse en dos tipos, que ilustramos con los siguien- tes ejemplos basados en la relacién EMP_DEPT: # Si queremos insertar la tupla de un nuevo empleado en EMP_DEPT, debemos incluir los valo- res de los atributos del departamento al que pertenece, o bien nulos (si el empleado todavia no pertenece a ningtin departamento). Por ejemplo, para insertar una nueva tupla de un em- pleado que pertenece al departamento 5, debemos introducir correctamente los valores del departamento 5 para que sean consistentes con los valores del departamento 5 de otras tuplas de EMP_DEPT. En el disefio de la Figura 14.2, no tenemos que preocuparnos por este problema de congruencia ya que sélo introduciremos el mimero del departamento en la tupla del em- pleado; todos los demas atributos del departamento 5 se registraran una sola vez en la base de datos, como una tupla tinica de Ia relaci6n DEPARTANENTO. © Es dificil insertar en la relacién EMP_DEPT un nuevo departamento que todavfa no tenga em- pleados, La tinica forma de hacer esto es colotar valores nulos en los atributos de empleado. Esto originaré un problema porque NSS es la clave primaria de EMP_DEPT, y se supone que cada tupla representa una entidad empleado, no una entidad departamento. Es més, cuando se asigne el primer empleado a ese departamento ya no necesitaremos la tupla con valores nu- los. Este problema no se presentar4 en el disefio de la Figura 14.2, porque los departamentos se introducen en la relaci6n DEPARTAMENTO sin importar si algdn empleado pertenece a ellos 0 no; y siempre que un empleado se asigne a ese departamento se insertaré una tupla corres- pondiente en EMPLEADO. Anomalias de eliminacién, Este problema se relaciona con la segunda situacién de anomalfa de insercién que acabamos de ver. Si eliminamos de EMP_DEPT una tupla de empleado que representa al titimo empleado perteneciente a un cierto departamento, la informacién concemiente a ese de- partamento se perderd de la base de datos. Este problema no ocurre en la base de datos de la Figu- ra 14.2, porque las tuplas de DEPARTAMENTO se almacenan aparte. Anomalias de modificacién. En EMP_DEPT, si alteramos el valor de uno de los atributos de un departamento dado, por ejemplo el jefe.del departamento 5, deberemos actualizar las tuplas de to- dos los empleados que pertenezcan a ese departamento; de lo contrario, la base de datos se volverd inconsistente. Si dejamos algunas tuplas sin actualizar, el mismo departamento tendra dos valores distintos para el jefe en diferentes tuplas de empleado, lo que no debe suceder. Basdndonos én las tres anomalfas anteriores, podemos enunciar la siguiente pauta: PAUTA 2: disefie los esquemas de las relaciones de base de modo que no haya anomalfas de in- serci6n, eliminacién o modificacién en las relaciones. Si hay anomalias, sefiélelas con claridad a fin de que los programas que actualicen la base de datos operen correctamente. La segunda pauta es congruente con la primera y, en cierta forma, es otro modo de expresarla. También podemos percatamnos de la necesidad de un mecanismo més formal para evaluar si un disefio sigue o no estas pautas. De la Seccidn 14.2 a la 14.4 se presentaran estos conceptos forma- les necesarios. Es importante sefialar que hay ocasiones en las que es preciso violar estas pautas para mejorar el rendimiento de ciertas consultas. Por ejemplo, si una consulta importante obtiene informacién relativa al departamento de un empleado, junto con los atributos del empleado, el es- quema ENP_DEPT puede servir como relacién de base. Sin embargo, debemos tomar nota de las anomalfas de EMP_DEPT y entenderlas perfectamente de modo que al actualizar la relacién de base no se produzcan inconsistencias. En general, es aconsejable usar relaciones de base libres de anomalfas y especificar vistas que incluyan las reuniones para colocar los atributos a los que fre- cuentemente: se hace referencia en consultas importantes. Esto reduce el nimero de términos de446 — Fundamentos de sistemas de bases de datos reuni6n especificados en la consulta, lo que facilitard su escritura correcta y en muchos casos me- joraré el rendimiento.° 14.1.3. Valores nulos en las tuplas En algunos disefios de esquemas quiz4 agruparemos muchos atributos para formar una relacién «gruesa>, Si muchos de los atributos no se aplican a todas las tuplas de la relacién, acabaremos con un gran nimero de nulos en esas tuplas. Esto puede originar un considerable desperdicio de espacio en el nivel de almacenamiento y posiblemente dificultar el entendimiento del significado de los atributos y la especificacién de operaciones de REUNION en el nivel légico.* Otro proble- ma con los nulos es cémo manejarlos cuando se aplican funciones agregadas como COUNT o SUM. Ademés, los nulos pueden tener miltiples interpretaciones, como las siguientes: * El atributo no se aplica a esta tupla. # Se desconoce el valor del atributo para esta tupla. * El valor se conoce pero estd ausente; esto es, todavia no se ha registrado. Tener la misma representacién para todos los nulos puede hacer que se confundan los diferen- tes significados que podrfan tener. Por lo tanto, podemos expresar otra pauta como sigue: PAUTA 3: hasta donde sea posible, evite incluir en una relaci6n base atributos cuyos valores pue- dan ser nulos, Si no es posible evitar los nulos, asegtirese de que se apliquen s6lo en casos excep- cionales y no a la mayorfa de las tuplas de una relacién. Por ejemplo, si sélo el 10 por ciento de los empleados tiene oficinas individuales, no se justifi- card incluir un atributo NUM_OFICINA en la relacién EMPLEADO, mds bien, podrfamos crear una rela- cién OFICINAS_EMPS (NSS, NUM_OFICINA) que contenga exclusivamente tuplas para los empleados con oficinas individuales. 14.1. Generacién de tuplas espurias Consideremos los dos esquemas de relacién Locs_eMP y EMP_PROY! de la Figura 14.5(a), que po- drfamos usar en vez de la relacién EMP_PROY de la Figura 14.3(b). Una tupla en LOCS_EMP significa que el empleado cuyo nombre es NOMBRE trabaja en algiin proyecto cuya ubicacién es LOCALIZA- CIONP. Una tupla en EMP_PROY1 significa que el empleado cuyo niimero de la seguridad social es NSS trabaja HORAS por semana en el proyecto cuyo nombre, niimero y ubicacién son NOMBREP, NU- MEROP y LOCALIZACIONP, La Figura 14.5(b) muestra extensiones de las relaciones LOCS_EMP y EMP_PROY1 que corresponden a la relacién EMP_PROY de la Figura 14.4 y que se obtienen aplicando las operaciones PROYECTO (7) apropiadas a EMP_PROY (haga caso omiso por ahora de las lineas punteadas en la Figura i4.5(b)). Supongamos que EMP_PROY1 y LOCS_EMP son las relaciones de base, en vez de EMP_PROY. Esto producé un disefio de esquema particularmente insatisfactorio, porque no es posible recuperar la ® El rendimiento de una consulta especificada sobre una vista que es la reunién de varias relaciones de base depende de la manera en que el SGBD implemente la vista. Muchos SGBD relacionales materializan tima vista que se use con frecuen- cia para no tener que realizar las reuniones con esa frecuencia, Sigue siendo obligaci6n del SGBD actualizar 1a vista mate- rializada (bien inmediatamente o periddicamente) cada vez que se actualizan las relaciones de base. * Ello es debido a que las reuniones internas y externas generan resultados diferentes cuando se incluyen nulos en las, reuniones. Por consiguiente, los usuarios deben ser conscientes de los diferentes significados de los diversos tipos de reu- niones. Aungue esto resulta razonable para usuarios expertos, puede ser dificil para otros.Dependencias funcionales y normalizacién en bases-de datos relacionales 447 @ Locs EMP | NOMBREE | LOCALIZACIONP. —_— ob. EMP_PROY1 NSS_]| NUMEROP | HORAS |. NOMBREP | LOCALIZACIONP ———ee, dp. 0) Locs_EMP NOMBREE LOCALIZACIONP. ‘Smit, John B. Bellaire Sith, John B. ‘Sugavland Narayan, Ramesh K. Houston, English, Joyoe A. Bellaire English, Joyoe A. Sugattand Wong, Frankin T. Sugarland Wong, renin Houston Stafiord EMP_PROY1 Nss NUMEROP | HORAS | NOMBREP | LOCALIZACIONP 123466769 1 825 ProductoX Belare 123456789 2 75 Producto Y_ ‘Sugarland eseaedadd 3 400 Producto Houston 453453453 1 20,0 Producto X Bellaire 2 20,0 Producto Y_ ‘Sugartand 2 100 Producto Y_ ‘Sugarland 3 10,0 Producto Z Houston 0 Staford 300) 10 400 10 350 30 50 30 200 20 150 Houston 20 snulo Houston Figura 14.5. Representacién alternativa (mala) de !a relacién eup_proy. (a) Representacién de ewp_Prov de la Figura 14.3(b) con dos esquemas de relacién: Locs_enp y eup_prov1. (b) Resultado de proyectar la relacién eup_proy de la Figura 14.4 sobre los atributos de euP_PROY! y LOcS-EWP. informacién contenida originalmente en EMP_PROY a partir de EMP_PROY1 y LOCS_EMP. Si intenta- mos una operacién de REUNION NATURAL con EMP_PROY1 y LOCS.EMP obtendremos muchas448 — Fundamentos de sistemas de bases de datos més tuplas de las que tenfa EMP_PROY. En la Figura 14.6 se muestra s6lo el resultado de aplicar la reuni6n a las tuplas que estén encima de las Iineas punteadas de la Figura 14.5(b) para reducir el tamafio de la relacién resultante. Las tuplas adicionales que no estaban en EMP_PROY se denominan tuplas espurias porque representan informacién espuria o errénea que no es valida. En la Figu- ra 14.6 las tuplas espurias estén marcadas con asteriscos (*). La descomposicién de EMP_PROY en LOCS.EMP y EMP_PROY1 no es satisfactoria porque, cuando las reunimos otra vez con una REUNION NATURAL, no obtenemos la infermacién original co- rrecta. Esto se debe a que LOCALIZACIONP es un atributo que relaciona LOCS_EMP y EMP_PROY1, y LOCALIZACIONP no es ni clave primaria ni clave externa en cualquiera de esas dos relaciones. Aho- ra podremos expresar informalmente otra pauta de disefio. PAUTA 4: disefie los esquemas de relacién de modo que puedan REUNIRSE mediante condicio- nes de igualdad sobre atributos que sean claves primarias 0 claves externas, a fin de garantizar que no se formardn tuplas espurias. No incluya relaciones que contengan atributos coincidentes que no sean combinaciones de clave externa-clave primaria. Si no se pueden evitar este tipo de relaciones, no las retina con dichos atributos porque la reunién puede dar lugar a tuplas espurias. Es obvio que esta pauta informal deberd expresarse de manera mds formal. En el Capitulo 15 trataremos una condicién formal, la lamada propiedad de reunién no aditiva (0 sin pérdidas), con Ia que se garantizar4 que ciertas reuniones no produciran tuplas espurias. 14.1.5. Resumen y anialisis de las pautas de disefio De la Secci6n 14.1.1 a la 14.1.4 estudiamos informalmente situaciones que dan origen a esquemas de relacién problematicos y propusimos pautas informales para un buen disefio relacional. Los pro- Nss [NUMEROP] HORAS | NOMBREP | LOCALIZACIONP | _NOMBREE 123456789 1 925 ProductoX Belaire ‘Smith John B. “2945678901 825 ProductoX Belaire English Joyoe A. 3234567892 75 ProductoY Sugariand ‘Smith,John B. "1234567892 75 ProductoY Sugartand English Joyoe A. "1234567892 75 ProductoY Sugariand Wong Frankin T. ecsse4a4 8 400 ProductoZ Houston, Narayan, Ramesh. ro0eses4ad 3 400 ProductoZ Houston Wong Frankin T. "453454531 200 Productox Belaire Smith John B. 4534504531 200 ProductoX Belaire English Joyoe A. “450453453 2 200 ProductoY ‘Sugarland ‘Smith John B. 4534534532 200 ProductoY Sugariand Englsh.Joyoe A. 14534504532 200 ProductoY Sugeriand ‘Wong Franklin. 1393445555 2 100 ProductoY ‘Sugariand Smrith,John B. "399ed5555 2 100 ProductoY ‘Sugarland English.Joyoe A. saaaasses 2 100 ProductoY ‘Sugeriand ‘Wong FrankinT. "3994455553 100 ProductoZ Houston Narayan Ramesh K. ssessss 8 10.0 ProductoZ Houston ‘Wong Frankin T. 33344555510 10.0 Computerizacion Stafford ‘Wong Frankin T. "393445555. 20 10.0 Reorganizacion Houston Narayan,Ramesh K. 330445555 20 10.0 Reorganizacién Houston ‘Wong Frankin T. Figura 14.6, Resultado de aplicar la operacién REUNION NATURAL a las tuplas que estén por encima de las lineas punteadas de euP_pAov: y Locs_ex, con las tuplas espurias generadas marcadas con un asterisco (*).Dependencias funcionales y normalizacién en bases de datos relacionales 449 blemas que sefialamos, y que pueden detectarse sin herramientas adicionales de andlisis, son los siguientes: © Anomalias que suponen que se realice un trabajo adicional durante la insercién y modifica- cién de una relacién, y que pueden causar una pérdida accidental de informaci6n durante la eliminaci6n de una relacién. © Desperdicio de espacio de almacenamiento debido a los valores nulos y a la dificultad de llevar a cabo operaciones de agregacién y reuniones a causa de los valores nulos. © Generacién de datos invélidos y espurios durante las reuniones sobre relaciones de base rela- cionadas inadecuadamente. En lo que resta del capitulo expondremos conceptos y teorfas formales con los que podremos definir con mayor precisién Jo Yen R, no nos dice si YX en Ro no. Las dependencias funcionales son propiedades de la semintica o del significado de los atribu- tos. Los disefiadores de bases de datos aprovecharn su conocimiento de la seméntica de los atribu- tos de R (es decir, qué relacién hay entre ellos) para especificar las dependencias funcionales que deben cumplirse en todos los estados de relacién (extensiones) r de R. Siempre que la semAntica de dos conjuntos de atributos de R indique que debe cumplirse una dependencia funcional, especifica- remos esa dependencia como una restriccién. Las extensiones de relacién r(R) que satisfagan las resiricciones de dependencia funcional se denominarén extensiones permitidas (0 estados de re- lacién permitidos) de R, porque obedecen a las restricciones de dependencia funcional. Por consi- guiente, la utilidad principal de las dependencias funcionales es describir mejor un esquema de relacién R mediante la especificacién de restricciones sobre sus atributos que deben cumplirse en todo momento. Ciertas DF pueden especificarse sin hacer referencia a una relaci6n especffica, sino como una propiedad de dichos atributos. Por ejemplo, (Estado, ntmero_permiso_conductor} > Nss deberfa valer para cualquier adulto de los Estados Unidos. También es posible que determina- das dependencias funcionales puedan dejar de existir en el mundo real si se modifica la relacién. Por ejemplo, la DF Cédigo_postal — Cédigo_area empleada para establecer una relacién entre los cédigos postales y los prefijos telef6nicos en los EEUU, ya no es valida debido a la prolifera- cién de cédigos de érea. Consideremos el esquema de relaci6n EMP_PROY de la Figura 14.3(b); a partir de la seméntica de los atributos, sabemos que deben cumplirse las siguientes dependencias funcionales: a) NSS — NOMBRE b) NUMEROP -+ {NOMBREP, LOCALIZACIONP} c) {NSS, NUMEROP} + HORAS Estas dependencias funcionales especifican que (a) el valor del mimero de la seguridad social de un empleado Nss determina de manera tinica el nombre de ese empleado (NOMBREE), (b) el valor del némero de un proyecto (NUMEROP) determina de manera tnica el nombre del proyecto (NOM BREP) y su lugar (LOCALIZACIONP), y (c) una combinacién de valores de NSS y NUMEROP determina de manera tinica el ntimero de horas que el empleado trabaja en el proyecto cada semana (HORAS). Otra posibilidad es decir que NOMBRE estd determinado funcionalmente por (0 depende funcio- nalmente de) NSS, 0 «dado un valor de NSS, conocemos el valor de NOMBREE>, y asi sucesiva- mente. Una dependencia funcional es una propiedad del esquema de relacién (intensién) R, no de un estado de relaci6n permitida (extensi6n) r de R en particular. Por lo tanto, una DF no puede inferit- se autométicamente de la extensi6n'de una relacién dada r sino que debe definirla explicitamente alguien que conozca la seméntica de los atributos de R. Por ejemplo, la Figura 14.7 ilustra un esta- do de relacién especifico del esquema de relacién IMPARTE. Aunque a primera vista podrfamos sen-Dependencias funcionales y normalizacién en bases de datos relacionales 451 IMPARTIR: PROFESOR CURSO TEXTO ‘Smith Estructuras de dalos Bartram Smith Gestion de datos ALNour Hal ‘Compiiadores Hotiman Brown —_Estructuras de datos Augenthaler Figura 14.7. Estado de la relacién iwpaate con una dependencia funcional aparente Texro curso. Sin embargo, curso-» texto estd descartada. timos tentados a decir que TEXTO— CURSO, no podemos confirmar esto a menos que sepamos que se cumple para todos los posibles estados de relacién permitidos de IMPARTE. Por otro lado, basta con presentar un solo contraejemplo para demostrar que no existe una dependencia funcional. Por ejemplo, del hecho de que ‘Smith’ imparta tanto “Estructuras de datos’ como ‘Gestién de datos’ podemos concluir que PROFESOR no determina funcionalmente CURSO. La Figura 14.3 presenta una notacién gréfica para indicar las dependencias funcionales: cada DF se muestra como una Ifnea horizontal. Los atributos de la parte izquierda de la DF se conectan mediante Iineas verticales a la linea horizontal que representa la DF. Los atributos de la parte dere- cha de la DF se conectan a la Ifnea horizontal mediante flechas que apuntan a los atributos, como se aprecia en las Figuras 14.3(a) y (b). 14.2.2. Reglas de inferencia para las dependencias funcionales Denotamos con F al conjunto de dependencias funcionales que se especifican sobre el esquema de relacién R. Por lo general, el disefiador del esquema especifica las dependencias funcionales que son semdnticamente obvias; pero es comin que muchas otras dependencias funcionales se cumplan en todas las instancias de relacién permitidas que satisfagan las dependencias de F. Las otras de- pendencias pueden inferirse 0 deducirse de las DF de F. Para los ejemplos de la vida real, resulta prdcticamente imposible especificar todas las dependencias funcionales que pueden darse. El con- junto de todas estas dependencias funcionales se denomina cierre de F y se denota con F*. Por ejemplo, supongamos que especificamos el siguiente conjunto F de dependencias funcionales ob- vias sobre el esquema de relacién de la Figura 14.3(a): F= {NSS ~ {NOMBREE, FECHA_NCTO, DIRECCION, NUMEROD}, NUMEROD — {NOMBRED, NSS_JEFED}} Podemos inferir las siguientes dependencias funcionales adicionales a partir de F: NSS — {NOMBRED, NSS_JEFED} NSS + NSS, NUMEROD -+ NOMBRED Una DF X + ¥ se infiere de un conjunto de dependencias F especificado sobre R si X -+ ¥ se cumple en todo estado de relacién r que sea una extensién permitida de R; es decir, siempre que r satisfaga todas las dependencias de F, XY también se cumple en r. El cierre F* de F es el conjunto de todas las dependencias funcionales que pueden inferirse de F. Para determinar una forma sistemética de inferir dependencias, tendremos que descubrir un conjunto de reglas de infe- rencia que pueda servir para deducir nuevas dependencias a partir de un conjunto dado de de- pendencias. A continuacién, veremos algunas de estas reglas de inferencia. Con la notacién452 Fundamentos de sistemas de bases de datos F|= X + ¥ denotaremos que la dependencia funcional X -> ¥ se infiere del conjunto de dependen- cias funcionales F. En el anélisis que sigue, usaremos una notaciGn abreviada para referirnos a las dependencias funcionales. Por comodidad, concatenaremos las variables de atributos y omitiremos las comas. Asf pues, la DF {X, Y} + Z se abreviara como XYZ y la DF (X, ¥, Z} > (U, V} se abreviard como XYZ — UV. Las seis reglas que siguen (RII a RI6) son reglas de inferencia bien conocidas para las dependencias funcionales: RII (regla reflexiva):” Si X = Y, entonces X > Y. RI2 (regla de aumento):® {X — Y¥}|= XZ — YZ. RIB (regia transitiva): {X > ¥, ¥ + Z)|= XZ. RI4 (regla de descomposicién o proyectiva): (X > YZ} |= X— ¥. RIS (regla de uni6n o aditiva): (X + Y, XZ} RIG6 (regla pseudotransitiva): {X + ¥, WY > Z} La regla reflexiva (RII) dice que un conjunto de atributos siempre se determina a sf mismo, lo cual es obvio. Debido a que RII crea dependencias que son siempre verdaderas, dichas dependen- cias de denominan triviales. Formalmente, una dependencia funcional X + ¥ es trivial si X > ¥; de Jo contrario, es no trivial. La regla de aumento (RI2) dice que afiadir el mismo conjunto de atribu- tos a los dos miembros, izquierdo y derecho, de una dependencia produce otra dependencia valida, Segiin RIB, las dependencias funcionales son transitivas. La regla de descomposicién RI4 dice que podemos quitar los atributos del miembro derecho de una dependencia; la aplicacién repetida de esta regla puede descomponer la DF X + (Ay, A>, .... A,} en el conjunto de dependencias (X —> A,, X Ay, ..., X > A,}. La regla de unién RIS nos permite hacer lo opuesto: combinar un conjunto de dependencias {X > A,, XA, «.. X->A,,} en una sola DF X—> (Ay, Agy ony An b> Todas las reglas de inferencia anteriores pueden demostrarse a partir de la definicién de depen- dencia funcional, ya sea por demostraci6n directa o por reduccién al absurdo. Una demostracién por reduccién al absirdo supone que la regla no se cumple y muestra que eso no es posible. A continuacién, demostraremos que las tres primeras reglas (RII a R13) son vélidas. La segunda de- mostracién es por reduccién al absurdo. DEMOSTRACION DE RI1 Supongamos que X > Y y que existen dos tuplas ¢, y r, en alguna instancia de la relacién r de R tales que #,[X] = #,{X]. Entonces, 1,[¥] = t,[¥] porque X = Y; por lo tanto, debe cumplirse X3Yenr. DEMOSTRACION DE RI2 (POR REDUCCION AL ABSURDO) Supongamos que X—> ¥ se cumple en un ejemplo de relacién r de R, pero que XZ YZ no se cumple. En tal caso, deben existir dos tuplas 1 y tf, en r tales que (1) 1,[X] = [X], (2) 1,17] = {¥], (3) [XZ] = 41XZ], y (4) 41¥Z] # t.[¥Z]. Esto no es posible porque a partir de (1) y (3) se deduce (5) 1,[Z] = 1,12], y a partir de (2) y (5) se deduce (6) t,[YZ] = [YZ], lo que contradice (4). 7 La regia reflexiva también se pude expresar como X +X; es decir, un conjunto cualquiera de atributos se determina funcionalmente a s{ mismo. * La regla de aumento también puede expresarse como {X > Y}| = XZ—> Y; es decir, aumentar los, atributos del miem- bro izquierdo de una DF producira otra DF vélida.Dependencias funcionales y normalizacién en bases de datos relacionales 453 DEMOSTRACION DE RI3 Supongamos que se cumplen (1) X > ¥ y (2) YZ en una relacién r. Entonces, para dos tu- plas cualesquiera t, y t, en r tales que 1,[X] = 1,[X], debemos tener (3) t,[¥] = f,[¥] por la su- posicién (1), y por lo tanto, también debemos tener (4) t,[Z] = ¢,[Z], por (3) y por la suposicién (2); por lo tanto, se debe cumplir X + Z en r. Con argumentos similares, podemos demostrar las reglas de inferencia RI4 a RI6 y cual- quier otra regla de inferencia valida. Sin embargo, una forma mas simple de demostrar que una regla de inferencia para dependencias funcionales es valida consiste en demostrarlas mediante reglas de inferencia cuya validez. ya se ha demostrado. Por ejemplo, podemos demostrar RI4, RIS y RIG a partir de RI, RI2 y RI3 como sigue: DEMOSTRACION DE RI4 (UTILIZANDO RI1, RI2 y RI3) 1, X— YZ (dado), 2. ¥YZ-+Y (por RI y sabiendo que YZ > ¥). 3. XY (por RIB en 1 y 2). DEMOSTRACION DE RI5 (UTILIZANDO RI, RI2 y RI3) XY (dado). XZ (dado). X— XY (por RI2 en 1 aumenténdolo con X; obsérvese que XX = X). XY — YZ (por R12 en 2 aumentindolo con ¥). XYZ (por RIB en 3 y 4). Bane DEMOSTRACION DE RIG (UTILIZANDO RI1, RI2 y RI3) 1. XY (dado). 2. WX +Z (dado). 3. WX > WY (con RI2 en 1 aumentandolo con W). 4. WX—+Z (con RIB en 3 y 2). Armstrong (1974) demostré que las reglas de inferencia RI, RI2 y RI3 son correctas y com- pletas. Con correctas queremos decir que, dado un conjunto de dependencias funcionales F especi- ficado sobre un esquema de relacién R, cualquier dependencia que podamos inferir de F con RI1, RI2 y RI3 se cumpliré en todos los estados de relacién r de R que satisfagan las dependencias de F. Con completas queremos decir que el empleo repetido de RI1, RI2 y RI3 para inferir dependen- cias hasta que no sea posible inferir mds dependencias producird el conjunto completo de todas las dependencias posibles que se pueden inferir de F. En otras palabras, el conjunto de dependencias F*, al que llamamos cierre de F, se puede determinar a partir de F utilizando sélo las reglas de inferencia RII, RI2 y RI3. Las reglas de inferencia RI1, RI2 y RI3 se conocen como reglas de inferencia de Armstrong. Por lo regular, los disefiadores de bases de datos especifican primero el conjunto de dependen- cias funcionales F que se pueden determinar sin dificultad a partir de la seméntica de atributos de R. Luego, se pueden usar las reglas RII, RI2 y RIB para inferir las dependencias funcionales adi- cionales que también se cumpliran en R. Una forma sistemética de determinar estas dependencias ° En realidad se conocen como axiomas de Armstrong. En sentido matemiético estricto, los axiomas (hechos dados) son las dependencias funcionales de F, pues suponemos que son correctas, mientras que RII, RI2 y RIB son las reglas de inferencia para deducir nuevas dependencias funcionales (nuevos hechos).454 Fundamentos de sistemas de bases de datos funcionales adicionales consiste en determinar primero todos y cada uno de los conjuntos de atri- butos X que aparezcan como miembro izquierdo de alguna dependencia funcional en F para des- pués determinar el conjunto de todos los atributos que dependen de X. Asf, para cada conjunto de atributos X, determinamos el conjunto X* de atributos determinados funcionalmente por X; X* se denomina cierre de X bajo F. Podemos usar el Algoritmo 14.1 para calcular X*. ALGORITMO 14.1. Determinacién de X", el cierre de X bajo F. Xr xX} Repetir Viejox* : = X*; para cada dependencia funcional Y + Z en F hacer Sixt 2 Yentonces Xt: =X" UZ; Hasta que (X* = viejox") ; EI Algoritmo 14.1 comienza por asignar a X* todos los atributos de X. Por RIL, sabemos que todos estos atributos dependen funcionalmente de X. En virtud de las reglas de inferencia RI3 y RI4, afiadimos atributos a X*, emplearido cada una de las dependencias funcionales en F. Segui- mos pasando por todas las dependencias en F (el bucle repetir) hasta que no se afiadan mAs atribu- tos a X* durante un recorrido completo de las dependencias en F (el bucle para). Por ejemplo, consideremos el esquema de relacién EMP_PROY de la Figura 14.3(b); por la seméntica de los atri- butos, especificamos el siguiente conjunto F de dependencias funcionales que deben cumplirse en EMP_PROY: F= {NSS > NOMBREE, NUMEROP — {NOMBREP, LOCALIZACIONP}., {NSS, NUMEROP} - HORAS } Con el Algoritmo 14.1 podemos calcular los siguientes conjuntos de cierre respecto a F: {NSS}* = {NSS, NOMBREE } {NUMEROP}* = {NUMEROP, NOMBREP, LOCALIZACIONP} {NSS, NUMEROP}* = {NSS, NUMEROP, NOMBREE, NOMBREP, LOCALIZACIONP, HORAS } 14.2.3. Equivalencia de conjuntos de dependencias funcionales En esta seccién analizaremos la equivalencia de dos conjuntos de dependencias funcionales. Pri- mero, daremos algunas definiciones preliminares. Un conjunto de dependencias funcionales E esté cubierto por un conjunto de dependencias funcionales F (0 bien, se dice que F cubre a E, si toda DF en E también esté en F*; es decir, E esté cubierto si toda dependencia en E puede inferirse a partir de F. Dos conjuntos de dependencias funcionales E y F son equivalentes si E* = F*. Asi pues, la equivalencia significa que todas las DF en E se pueden inferir de F y que todas las DF en F se pueden inferir de E; esto es, E es equivalente a F si se cumple que E cubre a F y que F cubre ak. Podemos determinar si F cubre a E calculando X* respecto a F para cada DF X + ¥ en E, y comprobando después que este X* incluya los atributos en ¥. Si esto se cumple para todas las DF en E, entonces F cubre a E. Determinamos si E y F son equivalentes verificando que E cubra a F y que F cubra a E.Dependencias funcionales y normalizacion en bases de datos relacionales 455 14.2.4. Conjuntos minimos de dependencias funcionales Un conjunto de dependencias funcionales F es mfnimo si satisface las siguientes condiciones: 1, Toda dependencia en F tiene un solo atributo en su parte derecha. 2. No podemos reemplazar ninguna dependencia X>A en F por una dependencia Y— A, donde ¥ es un subconjunto propio de X, y seguir teniendo un conjunto de dependencias equivalente a F. 3. No podemos quitar ninguna depéndencia de F y seguir teniendo un conjunto de dependen- cias equivalente a F. Podemos concebir un conjunto minimo de dependencias como un conjunto de dependencias que estd en una forma estdndar 0 candnica y sin redundancias. La condicién 1 garantiza que cada dependencia est en una forma canénica con un tinico atributo en la parte derecha.'° Las condicio- nes 2 y 3 garantizan que no habré redundancias en las dependencias bien teniendo los aiributos redundantes en el miembro izquierdo de una dependencia (condicién 2), 0 teniendo una dependen- cia que puede inferirse de las restantes DF en F (condicién 3). Una cobertura mfnima de un con- junto de dependencias funcionales F es un conjunto minimo de dependencias Fnjy que es equiva- lente a F. Desafortunadamente, un conjunto de dependencias funcionales puede tener varias coberturas minimas. Siempre podemos hallar por lo menos una cobertura minima G para cualquier conjunto de dependencias F empleando el Algoritmo 14.2. ALGORITMO 14.2. Hallar una cobertura minima G para F. 1. AsignarG: =F 2. Reemplazar cada dependencia funcional X + {A,, Ag, -.-, A} en G por las n dependen- cias funcionales X +A,,X > Az, -..,X +A, 3. Para cada dependencia funcional x >A enG para cada atributo B que sea un elemento de X si ((G - {X > A}) u {(X - {B}) + A}) es equivalente aG. entonces reemplazar X + A con (X - {8}) +AenG. 4. Para cada dependencia funcional restante X A enG si (G- {X + A}) es equivalente aG, entonces eliminar X + Ade G. ‘ uml tm rete em mar CCM laity erty Una vez estudiadas las dependencias funcionales y algunas de sus propiedades, ya podemos utili- zarlas como informacién sobre la semAntica de los esquemas de relacién. Suponemos que se da un conjunto de dependencias funcionales para cada relacién y que cada relacién tiene una clave pri- maria designada; esta informacién combinada con los tests (condiciones) para las formas normales conduce al proceso de normalizacién. Nos centraremos en las tres primeras formas para los esque- mas de relaci6n y en la idea intuitiva en la que se basan, y examinaremos cémo se desarrollaron éstas hist6ricamente. En la Secci6n 14.4 se pueden encontrar definiciones mas generales de estas formas normales que tienen en cuenta todas las claves candidatas de una relacién y no sélo la clave primaria. En la Seccién 14.5 definiremos la forma normal de Boyce-Codd (FNBC) y en el Capf- *© Esta es una forma esténdar, no un requisito, para simplificar las condiciones y los algoritmos que garantizan que no existe ningéin tipo de redundancia en F. Mediante la utilizacién de las reglas de inferencia RI4 y RIS, podemos convertir tuna dependencia tinica con mutitiples atributos en la parte derecha en un conjunto de dependencias, y viceversa.456 Fundamentos de sistemas de bases de datos tulo 15 definiremos formas normales adicionales que estén basadas en otros tipos de dependencias de datos. Primero, en la Seccién 14.3.1, analizaremos informalmente qué son las formas normales y qué motivos hubo para su creacién; ademas, recordaremos algunas de las definiciones del Capitulo 7 que vamos a necesitar aqui. A continuacién, explicaremos la primera forma normal (INF) en la Seccién 14.3.2, y presentaremos en las Secciones 14.3.3 y 14.3.4 la segunda forma normal (2FN) y Ja tercera forma normal (3FN), respectivamente, las cuales se basan en las claves primarias. 14.3.1 Introducci6n a la normalizacion En el proceso de normalizacién, segtin la propuesta original de Codd (1972a), se somete un esque- ma de relacién a una serie de pruebas para «certificar» si pertenece 0 no a una cierta forma nor- mal, El proceso, que sigue un estilo descendente evaluando cada relacién respecto a los criterios de normas formales y descomponiendo las relaciones a medida que sea necesario, puede conside- rarse por lo tanto un disefio relacional por andlisis. En un principio, Codd propuso tres formas normales, a las cuales llamé primera, segunda y tercera forma normal. Posteriormente, Boyce y Codd propusieron una definicién més estricta de 3FN, a la que se conoce como forma normal de Boyce-Codd (FNBC). Todas estas formas normales se basan en las dependencias funcionales entre los atributos de una relacién. Mas adelante, se propusieron una cuarta (4NF) y una quinta forma normal (SEN), basadas en los conceptos de dependencias multivaluadas y dependencias de reunién, respectivamente; éstas se estudiardn en el Capitulo 15. Al comienzo del mismo, también examina- remos el modo en el que se pueden sintetizar las relaciones 3NF a partir de un conjunto de DF dado. Este enfoque recibe el nombre de disefio relacional por sintesis. La normalizaci6n de los datos puede considerarse como un proceso de andlisis de los esque- mas de relacién dados basado en sus DF y claves primarias para alcanzar las propiedades deseables de (1) minimizar la redundancia y (2) minimizar las anomalfas de inserci6n, eliminacién y actuali- zacién estudiadas en la Seccién 14.1.2. Los esquemas de relacién insatisfactorios que no cumplan determinadas condiciones, las pruebas de formas normales, se descomponen en esquemas de re- lacién més pequeiios que satisfagan dichas pruebas y que de este modo posean las propiedades deseables. Por consiguiente, el procedimiento de normalizacién proporciona a los disefladores los siguientes aspectos: © Un marco formal para analizar los esquemas de relacién basndose en sus claves y en las dependencias funcionales entre sus atributos. © Una serie de pruebas de formas normales que pueden efectuarse sobre esquemas de relacién individuales de modo que la base de datos relacional pueda normalizarse hasta el grado de- seado, La forma normal de una relacién hace referencia a la condicién de forma normal més alta y de este modo, indica el grado al que ha sido normalizada. Las formas normales, cuando se conside- ran de manera aislada de otros factores, no garantizan un buen disefio de datos. En general, no basta con comprobar por separado que cada esquema de relacién de la base de datos esté en, diga- mos, FNBC 6 3FN. Més bien, el proceso de normalizacién por descomposici6n debe confirmar también la existencia de propiedades adicionales que los esquemas relacionales, en conjunto, de- ben poseer. Dos de estas propiedades son: * La propiedad de reunién sin pérdida o reunién no aditiva, que garantiza que no se pre- sentar4 el problema de las tuplas espurias que hemos visto en la Seccién 14.1.4, respecto a los esquemas de relacién tras la descomposicién.Dependencias funcionales y normalizacién en bases de datos relacionales ~ 457 jad de conservacién de las dependencias, que asegura que todas las dependen- cias funcionales estén representadas en algunas de las relaciones individuales resultantes tras la descomposicién. La propiedad de reuni6n no aditiva es sumamente critica y debe lograrse a toda costa, mientras que la propiedad de conservacién de las dependencias, aunque deseable, se sacrifica a veces, como veremos en la Seccién 15.1.2. Dejaremos para el Capitulo 15 la exposicién de los conceptos for- males y de las técnicas que garantizan las dos propiedades mencionadas. Las formas normales adicionales pueden definirse para que satisfagan otros criterios deseables, basados en tipos de restricciones adicionales, como veremos en el Capitulo 15. Sin embargo, la utilidad préctica de las formas normales queda en entredicho cuando a los disefiadores de bases de datos les resulta dificil comprender o detectar las restricciones en las que se basan y son los usuarios los que deben descubrir dichas restricciones. Por lo tanto, el disefio de bases de datos tal y como lo hace hoy en dfa la industria, presta una atencién especial a la normalizacin hasta FNBC 6 4EN. Otro punto que merece la pena destacar es que los disefiadores de bases de datos no tienen que normalizar hasta la forma normal més alta posible. Las relaciones pueden dejarse en formas nor- males inferiores por razones de rendimiento, como las que examinamos al final de la Seccién 14.1.2. El proceso de almacenar la reunién de relaciones, en la forma normal mas alta, como una relaci6n de base (que se encuentra en una forma normal inferior) se conoce como desnormalizacién. Antes de continuar, recordemos las definiciones de claves de un esquema de relacién que di- mos en el Capitulo 7. Una superclave de un esquema de relacién R = (Ay, Az, ... A,} eS un con- junto de atributos S & R con la propiedad de que no habré un par de tuplas f, y ) en ningtin estado de relaci6n permitido r de R tal que f,[5] = 1,15]. Una clave K es una superclave con la propiedad adicional de que la eliminacién de cualquier atributo de K hard que K deje de ser una superclave. La diferencia entre una clave y una superclave es que la primera tiene que ser minima; esto es, si tenemos una clave K = (Aj, Az, ..., Ay}, entonces K ~ {A,} no es una clave para 1 Y. En la Figura 14.3(b), {NSS, NUMEROP} — HORAS es una dependencia total (no se cumplen ni NSS —> HORAS ni NUMEROP —> HORAS). Sin embargo, la depen- dencia {NSS, NUMEROP} — NOMBREE es parcial porque se cumple que NSS —> NOMBREE. La prueba para’ 2FN incluye la verificacién de dependencias funcionales cuyos atributos del miembro izquierdo son parte de la clave primaria, Si la clave primaria contiene un tinico atributo, no es en absoluto preciso aplicar la prueba. Un esquema de relacién R esté en 2EN si todo atributo no primo A en R depende funcionalmente de manera total de la clave primaria de R. La relacién EMP_PROY de la Figura 14.3(b) est4 en IFN pero no en 2FN. El atributo no primo NOMBREE vio- la 2FN debido a DF2, y lo mismo sucede con los atributos no primos NOMBREP y LOCALIZACIONP debido a DF3. Las dependencias funcionales DF2 y DF3 hacen’ que NOMBREE, NOMBREP yDependencias funcionales y normalizacién en bases de datos relacionales 461 @ EMP_PROY NuMEROP | HORAS |NOMBREE|NOMBREP | LOCALIZACION I NORMALIZACION2-N ero ePt Ep2 nss_| numeror | Hors | [ ss |Nomerce] [ Numero | NoMBREP |LOCALIZACIONP et j oFe tn i f © EMP_DEPT NOMBRE} NSS [FECHA NOTO| DIRECCION | NUMEROD |NOMBRED| NSS_JEFED Lit +f NORMALIZAGION 3-N EDI D2 fNomanes| ues [FECHA Nero] DIRECCION [NUMERO] | NuwERCO [NoMBRED | NSS.JEFED a ff Figura 14.10. Proceso de normalizacién. (a) Normalizacién de eup_proy a relaciones en 2FN. (b) Normalizacién de eur_oePt a relaciones en 3FN. LOCALIZACTONP dependan parcialmente de la clave primaria {NSS, NUMEROP} de EMP_PROY, violén- dose asf la comprobacién de 2FN. Si un esquema de relaci6n no esté en 2FN, se le puede «normalizar en 2FN» dando lugar a varias relaciones 2FN en las que los atributos no primos estén asociados s6lo a la parte de la clave primaria de la que dependen funcionalmente de manera total. Asi, las dependencias fun- cionales DF1, DF2 y DF3 de la Figura 14.3(b) originan la descomposicién de EMP_PROY en los tres esquemas de relacién EP1, EP2 y EP3 que ilustra la Figura 14.10(a), cada uno de los cuales esté en 2EN. 14.3.4. Tercera forma normal La tercera forma normal (3NE) se basa en el concepto de dependencia transitiva. Una dependen- cia funcional X — ¥ en un esquema de relacién R es una dependencia transitiva si existe un con-462 Fundamentos de sistemas de bases de datos Tabi Resumen de las formas normales basadas en claves primarias y su normalizacién correspondiente, Forma normal Comprobacién Solucién (normalizacién) Primera (1FN) Una relacién no deberia tener ningun Formar relaciones nuevas para cada atributo no atémico ni relaciones atributo no atémico o relacién anidada. anidadas. Segunda (2FN) _Para las relaciones en las que la clave Descomponer y crear una nueva relacién imaria contiene multiples atributos, para cada clave parcial con su atributo 0 ningtin atributo no clave deberia atributos dependientes. Asegurarse de depender funcionalmente de una parte que se mantiene una relacién con la de la clave primaria. clave primaria original y todos los atributos que dependan funcionalmente de manera total de ella. Tercera (3FN) Una relacién no deberia tener un atributo Descomponer y crear una relacién que no clave determinado funcionalmente incluya el atributo o atributos no clave por otro atributo no clave (o por un que determinen funcionalmente a otro u conjunto de atributos no claves). Esto es, otros atributos no clave. no deberia existir una dependen transitiva por parte de un atributo no clave de una clave primaria, junto de atributos Z que no sea un subconjunto de cualquier clave de R,'* y se cumplen tanto X-—+Z como ZY. La dependencia NSS —+ NSS_JEFED es transitiva a través de NUMEROD de EMP_DEPT en la Figura 14.3(a), porque se cumplen las dos dependencias NSS —> NUMEROD y NUMEROD — NSS_JEFED y NUMEROD no es ni una clave en s{ misma ni un subconjunto de la clave de EMP_DEPT. Intuitivamente, podemos ver que en EMP_DEPT no es deseable la dependencia de NSS_JEFED con respecto a NUMEROD porque NUMEROD no es una clave de EMP_DEPT. De acuerdo con la definicién original de Codd, un esquema de relaci6n R esté en 3FN si esta en 2EN y ningun atributo no primo de R depende transitivamente de la clave primaria. El esquema de relacin EMP_DEPT de. la Figura 14.3(a) est4 en 2FN, pues no existen dependencias parciales sobre la clave, Sin embargo, no est en 3FN debido a que NSS_JEFED (y también NOMBRED) depen- den transitivamente de NSS a través de NUMEROD. Podemos normalizar EMP_DEPT descomponiéndolo en los dos esquemas de relacién en 3FN, EDI y ED2 que aparecen en la Figura 14.10(b). Intuitiva- mente, vemos que ED1 y ED2 representan hechos independientes acerca de las entidades emplea- dos y departamentos. Una operacién de REUNION NATURAL aplicada a EDI y ED2 recuperaré la relacion original EMP_DEPT sin generar tuplas espurias. La Tabla 14.1 resume de manera informal las tres formas normales basadas en claves prima- rias, las comprobaciones que se usan en cada caso y la «solucién» 0 normalizacién correspondiente para alcanzar la forma normal. 14.4. Definiciones generales de la segunda y tercera formas normales En general, queremos disefiar nuestros esquemas de relacién de modo que no tengan dependencias parciales ni transitivas, ya que estos tipos de dependencias provocan las anomalfas de actualizacién que vimos en la Seccién 14.1.2. Los pasos para la normalizaci6n en relaciones en 3NF que hemos 13 Bata es la definici6n general de dependencia transitiva. Como s6lo nos ocupamos de las claves primarias en esta seccién, permitimos dependencias transitivas en las que X es la clave primaria, pero Z puede ser (un subconjunto de) una clave candidateDependencias funcionales y normalizacion en bases de datos relacionales 463 visto hasta ahora prohfben las dependencias parciales y transitivas sobre la clave primaria. Sin em- bargo, estas definiciones no tienen en cuenta otras claves candidatas de una relacién, si existen. En esta seccién presentaremos las definiciones més generales de 2FN y 3FN que tienen en cuenta to- das las claves candidatas de una relacién. Cabe sefialar que esto no afecta a la definicién de IFN, ya que es independiente de las claves y de las dependencias funcionales. Como definicién general diremos que un atributo es primo cuando es parte de cualquier clave candidata. Las dependencias funcionales parciales y totales y las dependencias transitivas lo serén ahora respecto a todas las claves candidatas de una relacién. - 14.4.1. Dei ién general de la segunda forma normal Un esquema de relaci6n R est4 en segunda forma normal (2FN) si ningiin atributo no primo A de R depende parcialmente de alguna clave de R.'* Consideremos el esquema de relacién PARCELAS que aparece en la Figura 14.11(a) y que describe terrenos a la venta en diversos municipios de un estado. Supongamos que hay dos claves candidatas: ID_PROPIEDAD y (NOMBRE_MUNICIPIO, NUM_PARCELA}; es decir, los nimero de parcela son tinicos dentro de cada municipio, pero los ni- meros de ID_PROPIEDAD son tnicos para todo el estado, sin importar el municipio. Basdndonos en las dos claves candidatas ID_PROPIEDAD y {NOMBRE_MUNICIPIO, NUM_PARCELA}, sabemos que las dependencias funcionales DF1 y DF2 de la Figura 14.11(a) s{ se cumplen. Esco- gemos ID_PROPIEDAD como clave primaria, y por ello est4 subrayada en la Figura 14.11(a); pero no se dar ninguna consideracién especial a esta clave sobre la otra clave candidata. Supongamos que se cumplen las dos dependencias funcionales adicionales siguientes en PARCELAS: DF3: NOMBRE_MUNICIPIO > TASA_FISCAL DF4: AREA + PRECIO Si lo expresamos con palabras, la dependencia DF3 dice que la tasa fiscal es fija para un muni- cipio dado (no varia de una parcela a otra dentro del mismo municipio), y DF4 indica que el precio de una parcela lo determina su rea sin importar en qué municipio se encuentre (supongamos que éste es el precio de la pareela para fines fiscales). El esquema de relacién PARCELAS viola la defini- cién general de 2FN porque TASAFISCAL depende parcialmente de la clave candidata {NOMBRE_MUNICIPIO, NUM_LOTE#} debido a DF3. Para normalizar PARCELAS a 2FN, la descompone- mos en las dos relaciones PARCELAS1 y PARCELAS2 que se muestran en la Figura 14.11(b). Construi- mos PARCELAS! eliminando de PARCELAS el atributo TASA-FISCAL que viola 2FN y colocéndolo junto con NOMBRE_MUNICTPIO (la parte izquierda de DF3 que causa la dependencia parcial) en otra relacién PARCELAS2. Tanto PARCELAS1 como PARCELAS2 estén-en 2FN. Adviértase que la DF4 no viola la FN y persiste en PARCELAS1 14.4.2. Definicion general de la tercera forma normal Un esquema de relacin R est en tercera forma normal (3FN) si, siempre que una dependencia funcional no trivial X+A se cumple en R, o bien (a) X es una superclave de R, 0 (b) A es un atributo primo de R. De acuerdo con esta definicién, PARCELAS2 (Figura 14.11b) esta en 3EN. Sin embargo, la DF4 de PARCELAS1 viola la 3EN porque AREA no es una superclave y PRECIO no es un atributo primo de PARCELAS1. +4 Esta definicién puede expresarse como sigue: un esquema de relacién R esti en 2NF si todo atributo.no primo A de R depende funcionalmente de manera total de toda clave de R.Fundamentos de sistemas de bases de datos (2) PARCELAS ID_PROPIEDAD | NOMBRE MUNICIPIO | NUM_PARCELA. (0) PARCELAS! IO_PROPIEDAD | NOMBRE MUNICIPIO | NUM PARCELA | AREA PRECIO | oF i L_ tf PARCELAS2 NOMBRE MUNICIPIO | TASA FISCAL ()_ PARCELASTA PARCELASIB ID_PROPIEDAD | NOMBRE MUNICIPIO | NUM_PARCELA | AREA ‘AREA | PRECIO oe Dw Ld (6) PARCELAS 1-N PARCELAS! PARCELAS2 FN PARCELASIA PARCELASIB PARCELAS2 FN Figura 14.11. Normalizacién a 2FN y 3N. (a) El esquema de relacion panceLas y sus dependencias funcionales DF1 a DF4. (b) Descomposicién de pancetas en las relaciones en 2FN PARCELAST y PARCELAS2. (c) Descomposicion de PaRceLast en las relaciones en 3FN PARCELASTA y PARCELAS1B. (d) Resumen de la normalizacin de PARCELAS. Para normalizar PARCELAS1 a 3FN, la descomponemos en los esquemas de relacién PARCELAS1A Y PARCELAS1B, como en la Figura 14.11(c). Construimos PARCELAS1A eliminando de PARCELAS1 el atributo PRECIO que viola 3FN y colocdndolo junto con AREA (Ia parte izquierda de DF4 que causa Ja dependencia transitiva) en otra relacion PARCELAS1B. Tanto PARCELAS1A como. PARCELAS1B. estén en 3EN, Vale la pena destacar dos puntos acerca de la definicién general de 3FN:Dependencias funcionales y normalizacién en bases de datos relacionales 465 * PARCELAS1 viola 3FN porque PRECIO depende transitivamente de cada una de las claves can- didatas de PARCELAS1 a través del atributo no primo AREA. Esta definicién puede aplicarse directamente pata comprobar si un esquema de relacién esta en 3FN; no tiene que pasar primero por 2FN. Si aplicamos la definicion 3FFN a PARCELAS con las dependencias DF1 a DF4, veremos que tanto DF3 como DF4 violan la 3FN. Asi pues, podrfamos descomponer PARCELAS en PARCELAS1A, PARCELAS1B y PARCELAS2 directamente. Por lo tanto, las dependencias transitivas y parciales que violan 3FN pueden eliminarse en cualquier orden 14.4.3. Interpretacién de la defini in general de 3FN Un esquema de relacién R viola la definicién general de 3FN si una dependencia funcional X >A valida en R viola ambas condiciones (a) y (b) de 3FN. La violacién de (b) implica que-A es un atributo no primo. La violacién de (a) implica que X no es un superconjunto de ninguna clave de R; por lo tanto, X podrfa ser no primo o podrfa ser un subconjunto propio de una clave de R. Si X no es ptimo, por lo general tenemos una dependencia transitiva que viola 3FN, y si X es un sub- conjunto propio de una clave de R, tenemos una dependencia parcial que viola 3FN (y también 2FN). Por lo tanto, podemos expresar una definicién general alterniativa de 3FN como sigue: un esquema de relacién R est4 en 3FN si todo atributo no primo de R es: © Dependiente funcionalmente de manera total de toda clave de R. © Dependiente de manera no transitiva de toda clave de R. Forma normal de Boyce-Codd La forma normal de Boyce-Codd (FNBC) fue propuesta como una forma més simple que la 3FN, pero result6 ser mas estricta, dado que toda relacién que esté en FNBC también esta en 3FN; sin embargo, una relacién en 3FN no estd necesariamente en FNBC. Intuitivamente, podemos ver por qué es necesaria una forma normal més estricta que la 3FN si volvemos al esquema de relacién PARCELAS de la Figura 14.11(a) con sus cuatro dependencias funcionales DF1 a DF4. Supongamos que tenemos miles de parcelas en la relacién pero que dichas parcelas pertenecen a s6lo dos muni- cipios: Dekalb y Fulton. Supongamos también que los tamaiios de las parcelas en el municipio de Dekalb son de s6lo 0,5, 0,6, 0,7, 0,8, 0,9 y 1,0 hectéreas, mientras que los tamaiios de las parcelas en el municipio de Fulton estén restringidos a 1,1, 1,2, .... 1,9 y 2,0 hectéreas. En una situaci6n asi tendrfamos la dependencia funcional adicional DES: AREA — NONBRE_MUNIC. Si afladimos ésta a las demas dependencias, el esquema de relacién PARCELAS1 seguiré estando en 3FN porque NOM @RE_MUNIC es un atributo primo. La interrelacién del area y el municipio representada por DFS puede representarse con 16 tu- plas en una relacién aparte R(AREA, NOMBRE_MUNICTPIO), ya que slo hay 16 posibles valores del AREA. Esta representacin reduce la redundancia de repetit la misma informacién en las miles de tuplas PARCELAS1A. La FNBC es una forma normal mds estricta que prohibirfa PARCELASIA y suge- rirfa que habrfa que descomponerla. La definicién formal de Boyce-Codd difiere un poco de la definicién de 3FN. Un esquema de relacién R esté en FNBC si, siempre que una dependencia funcional no trivial X + A es valida en R, entonces X es una superclave de R. La Gnica diferencia entre FNBC y 3FN es que la condicién (b) de 3FN, que permite que A sea primo si X no es una superclave, esté ausente en FNBC.466 — Fundamentos de sistemas de bases de datos En nuestro ejemplo, la DF5 viola la FNBC en PARCELAS1A porque AREA no es una superclave de PARCELAS1A. Obsérvese que DFS satisface la 3FN en PARCELAS1A porque NOMBRE_MUNICIPIO es un atributo primo (condicién (b)), pero esta condicién no existe en la definicién de FNBC. Pode- mos descomponer PARCELASIA en las dos relaciones en FNBC PARCELAS1AX y PARCELAS1AY, que aparecen en la Figura 14.12(a). Esta descomposici6n pierde la dependencia funcional DF2 porque sus atributos ya no coexisten en la misma relacién. En la practica, casi todos los esquemas de relaci6n que estén en 3FN también estén en FNBC. Solo si existe una dependencia X + A en un esquema de relacién R, y X no es una superclave y A es un atributo primo, R estaré en 3FN pero no en FNBC. El esquema de relacién R que se aprecia en la Figura 14.12(b) ilustra el caso general de una relacién asf. Lo ideal seria que el disefio de bases de datos relacionales pudiese tener los esquemas de relacién en FNBC 0 en 3FN para cada esquema de relacién. Sin embargo, lograr el estado de normalizacién s6lo de 2FN o 1FN no se considera suficientemente adecuado, puesto que se desarrollaron hist6ricamente como escalones para llegar a 3FN y FNBC. La Figura 14.13 muestra una relacién IMPARTE con las siguientes de- pendencias: DFI: {ESTUDIANTE, CURSO} - PROFESOR DF2:'5 PROFESOR > CURSO @) PARCELAS1A ID_PROPIEDAD NOMBRE_MUNICIPIO | PARCELA | AREA oF f i 7 oe A 4 ; DFS en PARGELASIAK PARCELASIAY ID_PROPIEDAD Anca. | PARCELA ApEA | _NOMBAE_MUNICIPIO ) R A Bic o Clo oe A] Figura 14.12. Forma normal de Boyce-Codd. (a) Normalizacién a FNBC con la «pérdida» de la-dependencia DF2 en la descomposicion. (b) Relacion A que esté en 3FN Pero no en FNBC. 2 sta dependencia supone que «cada profesor imparte un curso» es una restriceiGn de esta aplicacién.Dependencias funcionales y normalizacién en bases de datos relacionales 467 IMPARTE ESTUDIANTE | CURSO PROFESOR Narayan Base de datos Mark ‘Smith Base de datos Navathe ‘Smith Sistemas operates Ammar ‘Smith Teoria ‘Schulman ‘Wallace Base de datos Mark ‘Wallace Sistemas operatives Ahamad ‘Wong Base de datos Omiecinski Zelaya Base de datos Navathe Figura 14.13. Relacién mare que esté en 3FN pero no en FNBC. Obsérvese que {ESTUDIANTE, CURSO} es una clave candidata para esta relaci6n y que las depen- dencias que se muestran siguen el patron de la Figura 14.12(b). Por lo tanto, esta relacién est4 en 3EN pero no en FNBC. La descomposicién de este esquema de relacién en dos esquemas no es sencilla porque puede descomponerse en uno de los tres pares posibles: 1. {ESTUDIANTE, PROFESOR} y {ESTUDIANTE, CURSO}. 2. {CURSO, PROFESOR} y {CURSO, ESTUDIANTE} 3. {PROFESOR, CURSO} y {PROFESOR, ESTUDIANTE}. Estas tres descomposiciones «pierden» la dependencia funcional DF1. La descomposicién de- seable de las tres anteriores es la tercera, porque no genera tuplas espurias después de una reunién. En la Seccién 15.1.3 se examina una prueba para determinar si una descomposicién es no aditiva (sin pérdidas) bajo la propiedad RSPI. En general, una relacin que no esté en FNBC deberfa des- componerse para satisfacer esta propiedad, al tiempo que posiblemente renuncie a conservar todas las dependencias funcionales en las relaciones descompuestas, como es el caso en este ejemplo. Esto es lo que hace el Algoritmo 15.3 que aparece en el capitulo siguiente y que podria haberse utilizado en el ejemplo anterior para obtener la misma descomposici6n para INPARTE. UC En este capitulo, estudiamos desde una perspectiva intuitiva varios errores que pueden cometerse al disefiar bases de datos relacionales, identificamos de manera informal algunas de las medidas que indican si un esquema de relacién es «bueno» 0 «malo» y explicamos ciertas pautas informales para lograr un buen disefio. A continuacién, presentamos algunos conceptos formales que nos per- miten realizar un disefio relacional de un estilo descendente analizando las relaciones individual- mente. Definimos este proceso de disefio mediante andlisis y descomposici6n presentando el pro- ceso de normalizacién. En el Capitulo 15, continuaremos con Jos temas tratados en este capitulo y examinaremos conceptos més avanzados de la teorfa del disefio relacional. ‘Analizamos los problemas de las anomalfas de actualizaci6n que tienen lugar cuando se presen- ta redundancia en las relaciones. Otras medidas informales de los buenos esquemas de relaci6n son una semédntica de atributos simple y clara y pocos nulos en las extensiones de las relaciones. Una468 — Fundamentos de sistemas de bases de datos buena descomposicién deberia evitar también el problema de la creacién de tuplas espurias como resultado de la operacién de reunién. Definimos el concepto de dependencia funcional y abordamos algunas de sus propiedades. Las ' dependencias funcionales son la fuente fundamental de informaci6n seméntica sobre los atributos de un esquema de relacién. Mostramos la forma de inferir dependencias adicionales a partir de un conjunto dado de dependencias funcionales empleando un conjunto de reglas de inferencia. Defini- mos los conceptos de cierre y cobertura minima de un conjunto de dependencias, y proporciona- mos un algoritmo para calcular la cobertura minima. También, mostramos cémo verificar si dos conjuntos de dependencias funcionales son equivalentes. Posteriormente, describimos el proceso de normalizacién para conseguir buenos disefios verifi- cando si se dan tipos no deseados de dependencias funcionales en las relaciones. Ofrecimos un tratamiento de normalizacién sucesiva basado en una clave primaria predefinida en cada relaci6n, y después relajamos este requisito y proporcionamos unas definiciones més generales de la segun- da forma normal (2FN) y la tercera forma normal (3FN) teniendo en cuenta todas las claves candi- datas de una relacién. Asimismo, ofrecimos ejemplos para ilustrar la forma de analizar y descom- poner una relacién dada empleando la definicién general de 3FN para obtener finalmente un conjunto de relaciones en 3EN. Por tiltimo, presentamos la forma normal de Boyce-Codd (FNBC) y examinamos por qué es mis estricta que 3FN. También ilustramos cémo descomponer una relacién que no esté en FNBC normalizada considerando el requisito de descomposicién no aditiva. El Capitulo 15 presentard los algoritmos de sintesis y de descomposicién para el disefio de ba- ses de datos relacionales a partir de dependencias funcionales. Relacionado con la descomposicién, estudiaremos los conceptos de reunién sin pérdida (no aditiva) y conservacién de dependencias, que estos algoritmos se encargan de asegurar. Otras cuestiones que abordaremos en el Capitulo 15 incluyen las dependencias multivaluadas, las dependencias de reunién y las formas normales adi- cionales que tienen en cuenta estas dependencias. Preguntas de repaso 14.1, Analice la seméntica de los atributos como medida informal de la Z)}|= {Wx}. b) (X+Y}eY2Z|= (xz). ©) (X+Y¥,X>W, WY+2Z}|= (XZ). d) {X¥>Z, ¥>W)|= {XW Z)}. (X>Z}. g) (XY, ZW) |= (XZ YW). h) (X¥+Z,Z>X)|= (ZY). i) (XY, ¥+2Z}|= {XYZ}. D {(XY-Z,Z>w} Considere los dos conjuntos siguientes de dependencias funcionales: F = {A—C, ACD, EAD, EH} y G = {A CD, EAH}. Compruete si son equivalentes. Considere el esquema de relacién EMP_DEPT de la Figura 14.3(a) y el siguiente conjunto G de dependencias funcionales sobre EMP_DEPT: G = {NSS + {NOMBREE, FECHA_NCTO, DI- RECCION, NUMEROD}, NUMEROD > {NOMBRED, NSS_JEFED}}. Calcule los cierres {NSS}* y {NUMEROD}* con respecto a G. {Es m{nimo el conjunto de dependencias funcionales G del Ejercicio 14.20? Si no, trate de encontrar un conjunto minimo de dependencias funcionales que sea equivalente a G. De- muestre que su conjunto es equivalente a G. {Qué anomalfas de actualizacién ocurren en las relaciones EMP_PROY y EMP_DEPT de las Figuras 14.3 y 14.4? GEn qué forma normal esté el esquema de relacién PARCELAS de la Figura 14.11(a) con respecto a las interpretaciones restrictivas de forma normal que tienen en cuenta sélo la clave primaria? ,Estarfa en la misma forma normal si se usaran las definiciones generales de forma normal? Demuestre que cualquier esquema de relacién con dos atributos esta en FNBC. {Por qué se producen tuplas espurias como resultado de reunir las relaciones EMP_PROY1 y LOCALIZACIONES.euP de la Figura 14.5 (cuyo resultado se muestra en la Figura 14.6)? Considere la relaci6n universal R = (A, B, C, D, E, F, G, H, I, J} y el conjunto de depen- dencias funcionales F = ({A, B)+{C}.{A} +{D, E}, {B} > (F), (F)>(G, A), {D} > (I, J}. ,Cuél es la clave de R? Descomponga R en relaciones que estén en 2EN y luego en 3EN. Repita el Ejercicio 14.26 para el conjunto siguiente de dependencias funcionales G = ({A, B} > {C}, {B, D} > {E, F}, {A, D} + (G, H), (A) > (1, (H} > (4). Considere la relaci6n siguiente: A B c TUPLA+ 10 bi cl #1 10 b2 2 oats au b4 cl #3 12 b3 4 4 13 bl cl bac 14 b3 4 #614.29. 14.30. 14.31, 14.32. Dependencias funcionales y normalizacién en bases de datos relacionales 471 a) Dada la extensién (estado) anterior, {cudles de las siguientes dependencias se pueden cumplir en la relacién anterior? Sino se puede cumplir ninguna, explique las razones especificando las tuplas que causan la violacién. i) A>B, ii) BoC, CB, iv) BoA, v) C>A b) cTiene esta relaci6n una clave candidata potencial? Si la tiene, ,cudl es? Si no la tie- ne, {por qué raz6n? Considere una relacién R(A, B, C, D, E) con las siguientes dependencias: ABC, CD>E, DE>B {Es AB una clave candidata de esta relaci6n? Si no, ;1o es ABD? Razone su respuesta. Considere la relacién R, que tiene los atributos que incluyen horarios de cursos y seccio- nes en una universidad; R = {NumCurso, Numsec, Deptoferta, HorasCrédito, Nivel- Curso, NSSProfesor, Semestre, Aflo, Horas_Dias, NumAula, NumEstudiantes}. Supon- gamos que se cumplen las siguientes dependencias en R: {NUmCurso} + {Deptoferta, HorasCrédito, NivelCurso} {NdmCurso, Nimsec, Semestre, Afo} -» {Horas_Dias, NumAula, NimEstudiantes, NSSProfesor} {NamAula, Horas_Dias, Semestre, Afio} > {NSSProfesor, Numcurso, Némsec} Intente determinar qué conjuntos de atributos constituyen claves de R. ,Cémo normaliza- ria esta relaci6n? Considere'las siguientes relaciones de una base de datos de aplicacién de procesamiento de pedidos en ABC Inc. PEDIDO (P+, FechaP, Cliente+, Cantidad_total) PEDIDO-ARTICULO (P#, A#, Cant_pedido, Precio_total, %Descuento) Suponga que cada articulo tiené un descuento diferente; el Precio-total se refiere a un articulo, FechaP es la fecha en la que se realiz6 el pedido, la Cantidad_total es la canti- dad del pedido. Si aplicamos una reuni6n natural a las relaciones PEDIDO-ARTICULO y PE- DIDO en la base de datos anterior, {c6mo serfa el esquema de relacién resultante? ;Cudl sera su clave? Muestre las DF de la relacién resultante. {Esté en 2FN y en 3FN? Razone su respuesta. (Explique sus suposiciones, si realiza alguna.) Considere la siguiente relacién: VENTA.COCHES (Coche#, Fecha_venta, Vendedor+, %Comisién, cant_descuento) Suponga que un coche puede ser vendido por multiples vendedores.y por lo tanto, (Co- che#, Vendedor#} es la clave primaria. Otras dependencias adicionales son: Fecha_venta + cant_descuento y Vendedor+ > %Comision. Baséindose en la clave primaria dada, jest esta relacién en IFN, 2FN 6 3FN? Explique su respuesta. ;Cémo la normalizarfa sucesivamente de forma completa?472 Fundamentos de sistemas de bases de datos 14.33. Considere esta relacién para libros publicados: LIBRO (Titulo_libro, NombreAutor, Tipo-libro, ListaPrecios, Afil_autor, Editor) Afil_autor se refiere a la afiliaci6n del autor. Suponga que se dan las siguientes depen- dencias: Titulo-libro + Editor, Tipo_libro Tipo_libro + ListaPrecios NombreAutor + Afil_autor a) En qué norma formal esté la relacién? Razone su respuesta. b) Aplique la normalizacién hasta que ya no pueda descomponer mis las relaciones. Ex- plique las razones de cada descomposicién. Bibliografia seleccionada Fue Codd (1970) quién introdujo originariamente las dependencias funcionales. Las definiciones originales de la primera, segunda y tercera forma normal fueron también definidas por Codd (1972a), quien abord6 las anomalfas de actualizacién. La forma normal de Boyce-Codd fue defini- da por Codd (1974). La definicién alternativa de la tercera forma normal la da Ullman (1988), al igual que la definicién de FNBC que hemos visto aqui. Ullman (1988), Maier (1983) y Atzeni y De Antonellis (1993) incluyen muchos de los teoremas y demostraciones relativos a las dependen- cias funcionales. Armstrong (1974) muestra la naturaleza correcta y completa de las reglas de inferencia RII, RI2 y RI3. En el Capitulo 15 se dan referencias adicionales a la teorfa del disefio relacional.