Cap.

2 Normalizacin de una Base de Datos

El proceso de normalizacin de una Base de Datos consiste en aplicar una serie de reglas a las relaciones obtenidas tras el paso del modelo E-R (entidad-relacin) al modelo relacional. Las bases de datos relacionales se normalizan para:

Evitar la redundancia de los datos. Evitar problemas de actualizacin de los datos en las tablas. Proteger la integridad de los datos.

En el modelo relacional es frecuente llamar tabla a una relacin, aun ue para ue una tabla bidimensional sea considerada como una relacin tiene ue cumplir con algunas restricciones:

!ada columna debe tener su nombre "nico. #o puede $aber dos filas iguales. #o se permiten los duplicados. %odos los datos en una columna deben ser del mismo tipo: (&R'!LE) o #()*ER, +#%E,ER, o !-'R, .'R!-'R/, o 0'%E 1 %+)E

Terminologa equivalente.

entidad 2 tabla o arc$ivo tupla 2 registro, fila o rengln atributo 2 campo o columna base de datos 2 banco de datos dependencia multivaluada 2 dependencia multivalor clave 2 llave (PR+)'R3, 4&RE+,#, (#+5(E 6E37) clave primaria 2 superclave (P6) clave ajena 2 clave e8terna o clave for9nea (46) RDB ! 2 del ingl:s Relational Data Base Manager System ue significa, Sistema Gestor de Bases de Datos Relacionales

Dependencia "uncional (na dependencia funcional son cone8iones entre uno o m9s atributos. Por e;emplo si conocemos el valor de Fecha de Nacimiento podemos conocer el valor de la Edad. Las dependencias funcionales se escriben utilizando una flec$a, de la siguiente manera: 4ec$a0e#acimiento#$Edad ' u< a %ec&aDeNacimiento se le conoce como un determinante. 7e puede leer de dos formas FechaDeNacimiento determina a Edad o Edad es funcionalmente dependiente de FechaDeNacimiento.

0e la normalizacin (lgica) a la implementacin (f<sica o real) puede ser sugerible tener :stas dependencias funcionales para lograr ma=or eficiencia en las tablas.

Dependencia "uncional transitiva 7upongamos ue en la relacin de la figura >.? los estudiantes solo pueden estar matriculados en un solo curso = supongamos ue los profesores solo pueden dar un curso. +0@Estudiante -A !urso@%omando !urso@%omando -A Profesor@'signado +0@Estudiante -A !urso@%omando -A Profesor@'signado Entonces tenemos ue 'D()studiante determina a Curso(Tomando = el Curso(Tomando determina a *ro"esor(+signado, indirectamente podemos saber a trav:s del 'D(estudiante el *ro"esor(+signado. Entonces en la figura >.? tenemos una dependencia transitiva.

Claves o ,laves
Clave candidata
Este registro de cada entrada en la tabla es imprescindible. +ndicar9 de forma un<voca la identidad de la entrada a la ue representa. Es $abitual usar un n"mero ue se incrementa con cada insercin, o autonum:rico. Puede $aber m9s de una clave candidata en una tabla. 7lo una de ellas actuar9 como clave primaria.

Clave alternativa -%.R)'/N 0)12

7on a uellas claves candidatas ue no $an sido seleccionadas como clave primaria.

Clave simple
Es una clave ue est9 compuesta de un solo atributo, pero ue est9 aparte en un sistema.

Clave compuesta -%034 %022

Es una clave ue est9 compuesta por m9s de un atributo.

%ormas Normales
En general, las primeras tres formas normales son suficientes para cubrir las necesidades de la ma=or<a de las bases de datos. El creador de estas B primeras formas normales (o reglas) fue Edgar 4. !odd, :ste introdu;o la normalizacin en un art<culo llamado A Relational Model of Data for Large Shared Data Banks !ommunications of t$e '!), .ol. >B, #o. C, Dune >EF?, pp. BFF-BGFH>I.

*rimera %orma Normal -3N%2

(na relacin est9 en Primera 4orma #ormal si = slo si todos los atributos son atmicos. (n atributo es atmico si los elementos del dominio son indivisibles, m<nimos. Por e;emplo: La Relacin:

cursos5 nombre, cdigo, vacantes, $orario, bibliograf<a

5ueda despu:s de aplicar la 4orma #ormal > de la siguiente manera:

cursos35 nombre, cdigo, vacantes &orario35 cdigo, d<a, mdulo bibliogra"ia35 cdigo, nombre, autor

)6) *,.25 PE0R& PE0R& )'R+' D('# '#'L+7%' PR&,R')'0&R !&#%'0&R +#,E#+ER&

(na columna no puede tener m"ltiples valores. Los datos son atmicos. (7i a cada valor de J le pertenece un valor de 3, entonces a cada valor de 3 le pertenece un valor de J).

!egunda %orma Normal -2N%2

0ependencia completa. (na relacin est9 en /#4 si est9 en >#4 = si los atributos ue no forman parte de ninguna clave dependen de forma completa de la clave principal. Es decir ue no e8isten dependencias parciales. Los atributos dependen de la clave. .ar<a la clave = var<an los atributos.

Tercera %orma Normal -7N%2

La tabla se encuentra en B#4 si es /#4 = cada atributo ue no forma parte de ninguna clave depende directamente = no transitivamente, de la clave primaria.

%orma Normal de Bo8ce#Codd -BCN%2

La tabla se encuentra en *!#4 si cada determinante, atributo ue determina completamente a otro, es clave candidata.

Reglas de Codd
!odd se percat de ue e8ist<an bases de datos en el mercado las cuales dec<an ser relacionales, pero lo "nico ue $ac<an era guardar la informacin en las tablas, sin estar estas tablas literalmente normalizadasK entonces :ste public >/ reglas ue un verdadero sistema relacional deber<a tener, en la pr9ctica algunas de ellas son dif<ciles de realizar. (n sistema podr9 considerarse Lm9s relacionalL cuanto m9s siga estas reglas. Regla No. 3 # ,a Regla de la in"ormacin L%oda la informacin en un R0*)7 est9 e8pl<citamente representada de una sola manera por valores en una tablaL. !ual uier cosa ue no e8ista en una tabla no e8iste del todo. %oda la informacin, inclu=endo nombres de tablas, nombres de vistas, nombres de columnas, = los datos de las columnas deben estar almacenados en tablas dentro de las bases de datos. Las tablas ue contienen tal informacin constitu=en el 0iccionario de 0atos. Regla No. 2 # ,a regla del acceso garantizado L!ada <tem de datos debe ser lgicamente accesible al e;ecutar una b"s ueda ue combine el nombre de la tabla, su clave primaria, = el nombre de la columnaL. Esto significa ue dado un nombre de tabla, dado el valor de la clave primaria, = dado el nombre de la columna re uerida, deber9 encontrarse uno = solamente un valor. Por esta razn la definicin de claves primarias para todas las tablas es pr9cticamente obligatoria. Regla No. 7 # Tratamiento sistem9tico de los valores nulos LLa informacin inaplicable o faltante puede ser representada a trav:s de valores nulosL. (n R0*)7 (7istema ,estor de *ases de 0atos Relacionales) debe ser capaz de soportar el uso de valores nulos en el lugar de columnas cu=os valores sean desconocidos o inaplicables. Regla No. : # ,a regla de la descripcin de la base de datos LLa descripcin de la base de datos es almacenada de la misma manera ue los datos ordinarios, esto es, en tablas = columnas, = debe ser accesible a los usuarios autorizadosL. La informacin de tablas, vistas, permisos de acceso de usuarios autorizados, etc, debe ser almacenada e8actamente de la misma manera: En tablas. Estas tablas deben ser accesibles igual ue todas las tablas, a trav:s de sentencias de 75L.

Regla No. ; # ,a regla del sub#lenguaje 'ntegral L0ebe $aber al menos un lengua;e ue sea integral para soportar la definicin de datos, manipulacin de datos, definicin de vistas, restricciones de integridad, = control de autorizaciones = transaccionesL. Esto significa ue debe $aber por lo menos un lengua;e con una sinta8is bien definida ue pueda ser usado para administrar completamente la base de datos. Regla No. < # ,a regla de la actualizacin de vistas L%odas las vistas ue son tericamente actualizables, deben ser actualizables por el sistema mismoL. La ma=or<a de las R0*)7 permiten actualizar vistas simples, pero des$abilitan los intentos de actualizar vistas comple;as. Regla No. = # ,a regla de insertar 8 actualizar LLa capacidad de mane;ar una base de datos con operandos simples aplica no solo para la recuperacin o consulta de datos, sino tambi:n para la insercin, actualizacin = borrado de datosL. Esto significa ue las cl9usulas 7ELE!%, (P0'%E, 0ELE%E e +#7ER% deben estar disponibles = operables sobre los registros, independientemente del tipo de relaciones = restricciones ue $a=a entre las tablas. Regla No. > # ,a regla de independencia "sica LEl acceso de usuarios a la base de datos a trav:s de terminales o programas de aplicacin, debe permanecer consistente lgicamente cuando uiera ue $a=a cambios en los datos almacenados, o sean cambiados los m:todos de acceso a los datosL. El comportamiento de los programas de aplicacin = de la actividad de usuarios v<a terminales deber<a ser predecible basados en la definicin lgica de la base de datos, = :ste comportamiento deber<a permanecer inalterado, independientemente de los cambios en la definicin f<sica de :sta. Regla No. ? # ,a regla de independencia lgica LLos programas de aplicacin = las actividades de acceso por terminal deben permanecer lgicamente inalteradas cuando uiera ue se $agan cambios (seg"n los permisos asignados) en las tablas de la base de datosL. La independencia lgica de los datos especifica ue los programas de aplicacin = las actividades de terminal deben ser independientes de la estructura lgica, por lo tanto los cambios en la estructura lgica no deben alterar o modificar estos programas de aplicacin.

Regla No. 3@ # ,a regla de la independencia de la integridad L%odas las restricciones de integridad deben ser definibles en los datos, = almacenables en el catalogo, no en el programa de aplicacinL. Las reglas de integridad son: >. #ing"n componente de una clave primaria puede tener valores en blanco o nulos. (esta es la norma b9sica de integridad). /. Para cada valor de clave for9nea deber9 e8istir un valor de clave primaria concordante. La combinacin de estas reglas aseguran ue $a=a +ntegridad referencial. Regla No. 33 # ,a regla de la distribucin LEl sistema debe poseer un lengua;e de datos ue pueda soportar ue la base de datos est: distribuida f<sicamente en distintos lugares sin ue esto afecte o altere a los programas de aplicacinL. El soporte para bases de datos distribuidas significa ue una coleccin arbitraria de relaciones, bases de datos corriendo en una mezcla de distintas m9 uinas = distintos sistemas operativos = ue este conectada por una variedad de redes, pueda funcionar como si estuviera disponible como en una "nica base de datos en una sola m9 uina. Regla No. 32 # Regla de la no#subversin L7i el sistema tiene lengua;es de ba;o nivel, estos lengua;es de ninguna manera pueden ser usados para violar la integridad de las reglas = restricciones e8presadas en un lengua;e de alto nivel (como 75L)L. 'lgunos productos solamente constru=en una interfaz relacional para sus bases de datos #o relacionales, lo ue $ace posible la subversin (violacin) de las restricciones de integridad. Esto no debe ser permitido.