1

C.B.T.i.s 243

Especialidad:

Ofimtica

Grupo: A

5to Semestre

Tema:

Las 3 formas normales para aplicar en un diseo

de BD

Docente:

Cornelio Alberto Prez Mndez

Nombre:

Jos Espnola Lpez Morales

23/de Septiembre/2015

2

INTRODUCCIN

Este trabajo est concebido para ser un seminario muy breve dirigido a los principiantes que quieren conseguir un dominio conceptual del proceso de normalizacin de bases de datos. Para demostrar los importantes principios tratados, tomaremos el clsico ejemplo de una Factura y la llevaremos hasta la Tercera Forma Normal. Tambin construiremos, por el camino, un Modelo Entidad - Relacin de la Base de Datos (BD)

Para empezar: Primero, memorice las 3 formas normales de tal forma que pueda recitarlas cuando duerma. El significado se ir aclarando por el camino. Solo memoricemos por ahora: 1. No elementos repetidos o grupos de elementos 2. Sin dependencias parciales de llaves concatenadas 3. Sin dependencias de atributos que no son llaves

3

Normalizacin de bases de datos

El proceso de normalizacin de bases de datos consiste en designar y aplicar una serie de reglas a las relaciones obtenidas tras el paso del modelo entidad-relacin al modelo relacional.

Las bases de datos relacionales se normalizan para:

Evitar la redundancia de los datos. Disminuir 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, aunque para que una tabla sea considerada como una relacin tiene que cumplir con algunas restricciones:

Cada tabla debe tener su nombre nico. No puede haber dos filas iguales. No se permiten los duplicados. Todos los datos en una columna deben ser del mismo tipo.

Figura 1.0: Trabajo (Cdigo, Nombre, Posicin, Salario), donde Cdigo es la Clave Primaria.

Relacin = tabla o archivo Registro = registro, fila , rengln o tupla Atributo = columna o campo Clave = llave o cdigo de identificacin Clave Candidata = superclave mnima Clave Primaria = clave candidata elegida Clave Ajena (o fornea) = clave externa o clave fornea Clave Alternativa = clave secundaria Dependencia Multivaluada = dependencia multivalor RDBMS = Del ingls Relational Data Base Manager System que

significa, Sistema Gestor de Bases de Datos Relacionales. 1FN = Significa, Primera Forma Normal o 1NF del ingls First Normal

Form.

Los trminos Relacin, Tupla y Atributo derivan del lgebra y clculo relacional, que constituyen la fuente terica del modelo de base de datos relacional.

4

LAS 3 FORMAS NORMALES PARA APLICAR EN UN DISEO DE BD

Primera forma normal (1FN)

Definicin: Para que una base de datos sea 1FN, es decir, que cumpla la primera forma normal, cada columna debe ser atmica.

Atmica significa "indivisible", es decir, cada atributo debe contener un nico valor del dominio. Los atributos, en cada tabla de una base de datos 1FN, no pueden tener listas o arrays de valores, ya sean del mismo dominio o de dominios diferentes.

Adems, cada atributo debe tener un nombre nico. Esto es algo que en general, al menos trabajando con MySQL, no nos preocupa; ya que la creacin de las tablas implica definir cada columna de un tipo concreto y con un nombre nico.

Tampoco pueden existir tuplas idnticas. Esto puede parecer obvio, pero no siempre es as. Supongamos una base de datos para la gestin de la biblioteca, y que el mismo da, y al mismo socio, se le presta dos veces el mismo libro (evidentemente, el libro es devuelto entre cada prstamo, claro). Esto producir, si no tenemos cuidado, dos registros iguales. Debemos evitar este tipo de situaciones, por ejemplo, aadiendo un atributo con un identificador nico de prstamo.

Como vemos, las restricciones de la primera forma normal coinciden con las condiciones de las relaciones de una base de datos relacional, por lo tanto, siempre es obligatorio aplicar esta forma normal.

Aplicar la primera forma normal es muy simple, bastar con dividir cada columna no atmica en tantas columnas atmicas como sea necesario. Por ejemplo, si tenemos una relacin que contiene la informacin de una agenda de amigos con este esquema:

Agenda (Nombre, email)

El nombre, normalmente, estar compuesto por el tratamiento (seor, seora,

don, doa, excelencia, alteza, seora, etc.), un nombre de pila y los apellidos.

Podramos considerar el nombre como un dato atmico, pero puede interesarnos

separar algunas de las partes que lo componen.

Y qu pasa con la direccin de correo electrnico? Tambin podemos

considerar que es un valor no atmico, la parte a la izquierda del smbolo @ es

el usuario, y a la derecha el dominio.

5

De nuevo, dependiendo de las necesidades del cliente o del uso de los datos,

podemos estar interesados en dividir este campo en dos, o incluso en tres partes

(puede interesar separar la parte a la derecha del punto en el dominio).

Tanto en esta forma normal, como en las prximas que veremos, es

importante no llevar el proceso de normalizacin demasiado lejos. Se trata

de facilitar el trabajo y evitar problemas de redundancia e integridad, y no

de lo contrario. Debemos considerar las ventajas o necesidades de aplicar

cada norma en cada caso, y no excedernos por intentar aplicar las normas

demasiado al pi de la letra.

El esquema de la relacin puede quedar como sigue:

Agenda (Nombre Tratamiento, Nombre Pila, Nombre Apellidos, email)

Otro caso frecuente de relaciones que no cumplen 1FN es cuando existen atributos multivariados, si todos los valores se agrupan en un nico atributo:

Libros (Titulo, autores, fecha, editorial)

Hemos previsto, muy astutamente, que un libro puede tener varios autores. No es que sea muy frecuente pero sucede, y ms con libros tcnicos y libros de texto.

Sin embargo, esta relacin no es 1FN, ya que en la columna de autores slo debe existir un valor del dominio, por lo tanto debemos convertir ese atributo en uno multivariado:

Libros

Titulo autor fecha editorial

Qu bueno es MySQL fulano 12/10/2003 La buena

Qu bueno es MySQL mengano 12/10/2003 La buena

Catstrofes naturales tulano 18/03/1998 Pentriga

6

Segunda forma normal (2FN)

Definicin: Para que una base de datos sea 2FN primero debe ser 1FN, y adems todas las columnas que formen parte de una clave candidata deben

aportar informacin sobre la clave completa.

Esta regla significa que en una relacin slo se debe almacenar

informacin sobre un tipo de entidad, y se traduce en que los atributos

que no aporten informacin directa sobre la clave principal deben

almacenarse en una relacin separada.

Lo primero que necesitamos para aplicar esta forma normal es identificar

las claves candidatas.

Adems, podemos elegir una clave principal, que abreviaremos como PK,

las iniciales de Primary Key. Pero esto es optativo, el modelo relacional

no obliga a elegir una clave principal para cada relacin, sino tan slo a la

existencia de al menos una clave candidata.

o La inexistencia de claves candidatas implica que la relacin no cumple todas las normas para ser parte de una base de datos relacional, ya que la no existencia de claves implica la repeticin de tuplas.

o En general, si no existe un candidato claro para la clave principal, crearemos una columna especfica con ese propsito.

o Veamos cmo aplicar esta regla usando un ejemplo. En este caso trataremos de guardar datos relacionados con la administracin de un hotel.

o Planteemos, por ejemplo, este esquema de relacin:

Ocupacin (No_cliente, Nombre_cliente, No_habitacin, precio_noche, tipo_habitacin, fecha_entrada)

1. Lo primero que tenemos que hacer es buscar las posibles claves

candidatas. En este caso slo existe una posibilidad:

2. (No_habitacin, fecha_entrada)

7

3. Recordemos que cualquier clave candidata debe identificar de forma

unvoca una clave completa. En este caso, la clave completa es la

ocupacin de una habitacin, que se define por dos parmetros: la

habitacin y la fecha de la ocupacin.

4. Es decir, dos ocupaciones son diferentes si cambian cualquiera de estos

parmetros. La misma persona puede ocupar varias habitaciones al

mismo tiempo o la misma habitacin durante varios das o en diferentes

periodos de tiempo. Lo que no es posible es que varias personas ocupen

la misma habitacin al mismo tiempo (salvo que se trate de un

acompaante, pero en ese caso, slo una de las personas es la titular de

la ocupacin).

5. El siguiente paso consiste en buscar columnas que no aporten

informacin directa sobre la clave completa: la ocupacin. En este caso el

precio por noche de la habitacin y el tipo de habitacin (es decir, si es

doble o sencilla), no aportan informacin sobre la clave principal. En

realidad, estos datos no son atributos de la ocupacin de la habitacin,

sino de la propia habitacin.

6. El nmero de cliente y su nombre aportan datos sobre la ocupacin,

aunque no formen parte de la clave completa.

Expresado en forma de dependencias se ve muy claro:

(No_habitacin, fecha_entrada) -> No_cliente (No_habitacin, fecha_entrada) -> Nombre_cliente No_habitacin -> precio_noche No_habitacin -> tipo_habitacin

8

Tercera forma normal 3FN

La tercera forma normal consiste en eliminar las dependencias transitivas. Definicin: Una base de datos est en 3FN si est en 2FN y adems

todas las columnas que no sean claves dependen de la clave completa de forma no transitiva.

Pero esto es una definicin demasiado terica. En la prctica significa que se debe eliminar cualquier relacin que permita llegar a un mismo dato de dos o ms formas diferentes.

Tomemos el ejemplo que usamos para ilustrar las dependencias funcionales transitivas. Tenemos una tabla donde se almacenen datos relativos a ciudades, y una de las columnas sea el pas y otra el continente al que pertenecen. Por ejemplo:

Ciudades (ID_ciudad (PK), Nombre, poblacin, superficie, renta, pas, continente)

Un conjunto de datos podra ser el siguiente:

Ciudades

ID_ciudad Nombre poblacin superficie renta pas continente

1 Paris 6000000 15 1800 Francia Europa

2 Lion 3500000 9 1600 Francia Europa

3 Berln 7500000 16 1900 Alemania Europa

4 Pekn 19000000 36 550 China Asia

5 Bonn 6000000 12 1900 Alemania Europa

Podemos ver que para cada aparicin de un determinado pas, el continente siempre es el mismo. Es decir, existe una redundancia de datos, y por lo tanto, un peligro de integridad.

Existe una relacin entre pas y continente, y ninguna de ellas es clave candidata. Por lo tanto, si queremos que esta table sea 3FN debemos separar esa columna:

Ciudades (ID_ciudad (PK), Nombre, poblacin, superficie, renta, nombre pas)

Pases (nombre pas (PK), nombre continente)

Ciudades

ID_ciudad Nombre poblacin superficie renta pas

1 Paris 6000000 15 1800 Francia

2 Lion 3500000 9 1600 Francia

3 Berln 7500000 16 1900 Alemania

4 Pekn 19000000 36 550 China

5 Bonn 6000000 12 1900 Alemania

Esta separacin tendra ms sentido si la tabla de pases contuviese ms informacin, tal como est no tiene mucho sentido separar estas tablas, aunque efectivamente, se evita redundan

9

Conclusin

Finalmente si tomamos en cuenta que una tabla de detalle de venta puede

contener un volumen de millones de registros, al haberle aplicado las 3 formas

normales nos estaremos ahorrando varios Gigabytes de tamao en dicha tabla

y por supuesto mejorado notablemente la performance

10

REFERENCIAS

https://es.wikipedia.org/wiki/Normalizaci%C3%B3n_de_bases_de_datos

https://cvva.wordpress.com/2007/12/04/normalizacion-de-bases-de-datos-las-3-

formas-normales/vvv

https://cvva.wordpress.com/2007/12/04/normalizacion-de-bases-de-datos-las-3-

formas-normales/

http://informatica.uv.es/estguia/ATD/apuntes/teoria/documentos/DisenoBD.pdf

http://mysql.conclase.net/curso/?cap=004