A travs del siguiente ejercicio se intenta afirmar los conocimientos de normalizacin con un ejemplo simplificado de una base de datos

para una pequea biblioteca.

CodLibro

Titulo

Autor

Editorial

NombreLector Prez Gmez, Juan Ros Tern, Ana Roca, Ren Garca Roque, Luis Prez Gmez, Juan

FechaDev

1001

Variable compleja Murray Spiegel

McGraw Hill

15/04/2005

1004 1005

Visual Basic 5 Estadstica

E. Petroustsos Murray Spiegel

Anaya McGraw Hill

17/04/2005 16/04/2005

1006

Oracle University

Nancy Greenberg Oracle Corp. y Priya Nathan

20/04/2005

1007

Clipper 5.01

Ramalho

McGraw Hill

18/04/2005

Esta tabla no cumple el requisito de la Primera Forma Normal (1NF) de slo tener campos atmicos, pues el nombre del lector es un campo que puede (y conviene) descomponerse en apellido paterno, apellido materno y nombres. Tal como se muestra en la siguiente tabla. 1NF CodLibro Titulo Variable compleja Visual Basic 5 Estadstica Oracle University Autor Editorial Paterno Materno Nombres FechaDev

1001

Murray Spiegel McGraw Hill Prez

Gmez

Juan

15/04/2005

1004 1005

E. Petroustsos Anaya

Ros

Tern

Ana Ren

17/04/2005 16/04/2005

Murray Spiegel McGraw Hill Roca Nancy Greenberg Oracle Corp.

1006

Garca

Roque

Luis

20/04/2005

CodLibro

Titulo Oracle University Clipper 5.01

Autor

Editorial Oracle Corp.

Paterno Materno Nombres FechaDev

1006

Priya Nathan

Garca

Roque

Luis

20/04/2005

1007

Ramalho

McGraw Hill Prez

Gmez

Juan

18/04/2005

Como se puede ver, hay cierta redundancia caracterstica de 1NF. La Segunda Forma Normal (2NF) pide que no existan dependencias parciales o dicho de otra manera, todos los atributos no clave deben depender por completo de la clave primaria. Actualmente en nuestra tabla tenemos varias dependencias parciales si consideramos como atributo clave el cdigo del libro. Por ejemplo, el ttulo es completamente identificado por el cdigo del libro, pero el nombre del lector en realidad no tiene dependencia de este cdigo, por tanto estos datos deben ser trasladados a otra tabla. 2NF CodLibro Titulo Variable compleja Autor Editorial

1001

Murray Spiegel

McGraw Hill

1004 1005

Visual Basic 5 E. Petroustsos Estadstica Oracle University Oracle University Clipper 5.01 Murray Spiegel

Anaya McGraw Hill

1006

Nancy Greenberg Oracle Corp.

1006

Priya Nathan

Oracle Corp.

1007

Ramalho

McGraw Hill

La nueva tabla slo contendr datos del lector.

CodLector 501 502 503 504

Paterno Prez Ros Roca Garca

Materno Gmez Tern

Nombres Juan Ana Ren

Roque

Luis

Hemos creado una tabla para contener los datos del lector y tambin tuvimos que crear la columna CodLector para identificar unvocamente a cada uno. Sin embargo, esta nueva disposicin de la base de datos necesita que exista otra tabla para mantener la informacin de qu libros estn prestados a qu lectores. Esta tabla se muestra a continuacin:

CodLibro CodLector 1001 1004 1005 1006 1007 501 502 503 504 501

FechaDev 15/04/2005 17/04/2005 16/04/2005 20/04/2005 18/04/2005

Para la Tercera Forma Normal (3NF) la relacin debe estar en 2NF y adems los atributos no clave deben ser mutuamente independientes y dependientes por completo de la clave primaria. Tambin recordemos que dijimos que esto significa que las columnas en la tabla deben contener solamente informacin sobre la entidad definida por la clave primaria y, por tanto, las columnas en la tabla deben contener datos acerca de una sola cosa. En nuestro ejemplo en 2NF, la primera tabla conserva informacin acerca del libro, los autores y editoriales, por lo que debemos crear nuevas tablas para satisfacer los requisitos de 3NF. 3NF

CodLibro

Titulo

CodAutor

Autor

CodEditorial

Editorial

1001 Variable compleja 1004 Visual Basic 5 1005 Estadstica 1006 Oracle University 1007 Clipper 5.01

801 Murray Spiegel 802 E. Petroustsos 803 Nancy Greenberg 804 Priya Nathan 806 Ramalho

901 McGraw Hill 902 Anaya 903 Oracle Corp.

Aunque hemos creado nuevas tablas para que cada una tenga slo informacin acerca de una entidad, tambin hemos perdido la informacin acerca de qu autor ha escrito qu libro y las editoriales correspondientes, por lo que debemos crear otras tablas que relacionen cada libro con sus autores y editoriales.

CodLibro 1001 1004 1005 1006 1006 1007

codAutor 801 802 801 803 804 806

CodLibro 1001 1004 1005 1006 1007

codEditorial 901 902 901 903 901

Y el resto de las tablas no necesitan modificacin.

CodLector Paterno Materno 501 Prez 502 Ros 503 Roca 504 Garca Roque Gmez Tern

Nombres Juan Ana Ren Luis CodLibro CodLector 1001 1004 1005 1006 1007 501 502 503 504 501 FechaDev 15/04/2005 17/04/2005 16/04/2005 20/04/2005 18/04/2005

Xxxxxxxxxxxxxxxxxxx
Clientes ID_Cliente Nombre Apellidos Nombre_Producto1 Costo_Producto1 Imagen_Producto1 Nombre_Producto2 Costo_Producto2 Imagen_Producto2 Fecha_Pedido Cantidad_Pedido Nombre_Cia_Envios

La tabla se ha descrito de manera abreviada pero aun as representa la idea general. Cmo podra aadir un nuevo cliente en su tabla Clientes? Debera aadir un producto y un pedido tambin. Qu tal si

quisiera emitir un informe de todos los productos que vende? No podra separar fcilmente los productos de los clientes con una simple instruccin SQL. Lo bello de las bases de datos relacionales, si estn bien diseadas, es que puede hacer esto fcilmente.

La nomlalizacin tambin hace las cosas fciles de entender. Los seres humanos tenemos la tendencia de simplificar las cosas al mximo. Lo hacemos con casi todo desde los animales hasta con los automviles. Vemos una imagen de gran tamao y la hacemos menos compleja agrupando cosas similares juntas. Las guas que la nomlalizacin provee crean el marco de referencia para simplificar la estructura. En su base de datos de muestra es fcil detectar que usted tiene tres diferentes grupos: clientes, productos y pedidos. Si sigue las guas de la nomlalizacin, podra crear las tablas basndose en estos grupos. El proceso de nomlalizacin tiene un nombre y una serie de reglas para cada fase. Esto puede parecer un poco confuso al principio, pero poco a poco ir entendiendo el proceso, as como las razones para hacerlo de esta manera. A la mayora de la gente le encantan las hojas de clculo por la forma en la que manejan sus datos. El tiempo que le lleve reconfigurar su esquema para ajustarlo al proceso de nomlalizacin, siempre ser bien Iinvertido. Al fin y al cabo, esto le tomar menos tiempo que el que tendra que invertir , para cortar y pegar sus columnas de datos para generar el infomle que quiere su jefe. Otra ventaja de la nomlalizacin de su base de datos es el consumo de espacio. Una base de datos nomlalizada puede ocupar menos espacio en disco que una no nomlalizada. Hay menos repeticin de datos, lo que tiene como consecuencia un mucho menor uso de espacio en disco. Grados de normalizacin Existen bsicamente tres niveles de normalizacin: Primera Fomla Normal (1NF), Segunda Fomla Normal (2NF) y Tercera Fomla Normal (3NF). Cada una de estas formas tiene sus propias reglas. Cuando una base de datos se conforma a un nivel, se considera nomlalizada a esa forma de nomlalizacin. Por ejemplo, supongamos que su base de datos cumple con todas las reglas del segundo nivel de nomlalizacin. Se considera que est en la Segunda Fomla Normal. No siempre es una buena idea tener una base de datos conformada en el nivel ms alto de normalizacin. Puede llevar aun nivel de complejidad que pudiera ser evitado si estuviera en un nivel ms bajo de normalizacin.

Primera Forma Normal La regla de la Primera Forma Normal establece que las columnas repetidas deben eliminarse y colocarse en tablas separadas. sta es una regla muy fcil de seguir. Observe el esquema de la tabla Clientes de la base de datos. . Clientes

ID Cliente Nombre Apellidos Nombre_Producto1 Costo_Producto1 Imagen_Producto1 Nombre_Producto2 Costo_Producto2 Imagen_Producto2 Fecha_Pedido Cantidad_Pedido Nombre Cia Envios

-La tabla tiene varias columnas repetidas. stas se refieren principalmente a los productos. De acuerdo con la regla, debe eliminar las columnas repetidas y crearles su propia tabla.

Eliminacin de datos repetidos en una base de datos

Clientes Pedidos ID_Clientes Nombre_Productos Nombre Costo_Producto Apellidos Imagen_Producto Direccion Numero_Pedido Fecha_Pedido Cantidad_Pedido Clave_Cia_Envios Nombre_Ci_ Envios -Ahora tiene dos tablas. Pero todava hay un problema. No hay forma de relacionar los datos de la tabla original con los de la nueva tabla. Para hacerlo, debe aadir un campo clave a la segunda tabla de forma que se establezca la relacin. Aada a la tabla Productos una clave primaria que se llame ID_Producto y aada una clave a la tabla Clientes que la relacione con la tabla Productos. El campo ID_Producto es el candidato ideal. Primera Forma Normal

Clientes Pedidos ID_Productos ID_Productos ID_Clientes Nombre_Productos Nombre Costo_Producto Apellidos Imagen_Producto Direccion Numero_Pedido Fecha_Pedido Cantidad_Pedido Clave_Cia_Envios

-As, se ha establecido una relacin uno a varios. sta representa lo que la base de datos estar haciendo en la vida real. El cliente tendr muchos productos que podr comprar, sin importar cuntos otros clientes quieran comprarlos tambin. Adems, el cliente necesitar haber pedido un producto para ser un cliente. Usted ya no est obligado a aadir

un cliente cada vez que aade un nuevo producto a su inventario.

Poner la base de datos en la Primera Forma Normal resuelve el problema de los encabezados de columna mltiples. Muy a menudo, los diseadores de bases de datos inexpertos harn algo similar a la tabla no normalizada. Una y otra vez, crearn columnas que representen los mismos datos. En una empresa de servicios de electricidad, haba una base de datos para el control de refacciones de una planta nuclear. La tabla de su base de datos, la cual contena los nmeros de parte de las refacciones, tena una columna repetida ms de treinta veces. Cada vez que una nueva parte se tena que dar de alta, se creaba una nueva columna para almacenar la informacin. Obviamente, el diseo de la base de datos era bastante pobre y, por lo mismo, resultaba una pesadilla para sus programadores/administradores. La normalizacin ayuda a clarificar la base de datos ya organizarla en partes ms pequeas y ms fciles de entender. En lugar de tener que entender una tabla gigantesca y monoltica que tiene muchos diferentes aspectos, usted slo tiene que entender objetos pequeos y ms tangibles, as como las relaciones que guardan con otros objetos tambin pequeos. No es necesario mencionar que un mejor entendimiento del funcionamiento de su base de datos conducir aun mejor aprovechamiento de sus activos. Segunda Forma Normal La regla de la Segunda Forma Normal establece que todas las dependencias parciales se deben eliminar y separar dentro de sus propias tablas. Una depen dencia parcial es un trmino que describe a aquellos datos que no dependen de la clave de la tabla para identificarlos. En la base de datos de muestra, la informacin de pedidos est en cada uno de los registros. Sera mucho ms simple utilizar nicamente el nmero del pedido. El resto de la informacin podra residir en su propia tabla. Una vez que haya organizado la informacin de pedidos. Eliminacin de las dependencias parciales -Segunda Forma Normal Clientes Pedidos Productos ID_Productos ID_Productos ID_Producto ID_Clientes Nombre_Productos Fecha_Compra Nombre Cantidad_Pedido Costos_Productos Apellidos Imagen_Producto Direccion Numero_Pedido Nombre_Cia_Envios

De nuevo, al organizar el esquema de esta forma puede reflejar el mundo real en su base de datos. Tendra que hacer algunos cambios en sus reglas del negocio para que esto fuera aplicable, pero para ilustrar la normalizacin, as est bien. Una de las mayores desventajas de la normalizacin es el tiempo que lleva hacerlo. La mayora de la gente est demasiado ocupada, y emplear tiempo para asegurarse de que sus datos estn normalizados cuando todo funciona ms o menos bien, parece ser un desperdicio de tiempo. Pero no es as. Usted tendr que emplear ms tiempo arreglando una base de datos no normalizada que el que empleara en una normalizada. Al haber alcanzado la Segunda Forma Normal, usted puede disfrutar de algunas de las ventajas de las bases de datos relacionales. Por ejemplo, puede aadir nuevas columnas a la tabla Clientes sin afectar a las tablas Productos y Pedidos. Lo mismo aplica para las otras tablas. Alcanzar este nivel de normalizacin permite que los datos se acomoden de una manera natural dentro de los lmites esperados. Una vez que ha alcanzado el nivel de la Segunda Forma Normal, se han controlado la mayora de los problemas de lgica. Puede insertar un registro sin un exceso de datos en la mayora de las tablas. Observando un poco ms de cerca la tabla Clientes, vemos la columna Nombre_Cia_Envios. sta no es dependiente del cliente. El siguiente nivel de normalizacin explicar cmo solucionar esto. Tercera Forma Normal La regla de la Tercera Forma Normal seala que hay que eliminar y separar cualquier dato que no sea clave. El valor de esta columna debe depender de la clave. Todos los valores deben identificarse nicamente por la clave. En la base de datos de muestra, la tabla Clientes contiene la columna Nombre_Cia_Envios, la cual no se identifica nicamente por la clave. Podra separar estos datos de la tabla y ponerlos en una tabla aparte.

Eliminacin de los datos que no son claves para la Tercera Forma Normal Clientes Productos PedidoMaestro PedidoDetallado Cias_Envios ID_cliente ID_Producto ID_Pedido ID_PedidoDetallado ID_Cia_Envios ID_Producto Nombre_Producto Fecha_Pedido ID_Pedido Nombre_Cia_Envios. Numero_Pedido Costos_Productos Cantidad_Pedidos Fecha_Pedido ID_Cia_Envios Foto_Producto Cantidad_Pedido Nombre Apellidos Direccion

Ahora todas sus tablas estn en la Tercera Forma Normal. Esto le da ms flexibilidad y previene errores de lgica cuando inserta o borra registros. Cada columna en la tabla est identificada de manera nica por la clave, y no hay datos repetidos. Esto provee un esquema limpio y elegante, que es fcil de trabajar y expandir. Qu tan lejos debe llevar la normalizacin La siguiente decisin es qu tan lejos debe llevar la normalizacin? La normalizacin es una ciencia subjetiva. Determinar las necesidades de simplificacin depende de usted. Si su base de datos va a proveer informacin aun solo usuario para un propsito simple y existen pocas posibilidades de expansin, normalizar sus datos hasta la 3FN sea quiz algo extremoso. Las reglas de normalizacin existen como guas para crear tablas que sean fciles de manejar, as como flexibles y eficientes. A veces puede ocurrir que normalizar sus datos hasta el nivel ms alto no tenga sentido. Por ejemplo, suponga que aade una columna extra para la direccin en su base de datos. Es muy normal tener dos lneas para la direccin. El esquema de la tabla podra verse como se muestra a continuacin: ID_Cliente Nombre Apellidos Direccion1 Direccion2 De acuerdo con las reglas, si aplica la Primera Forma Normal, la columna de direccin debera sacarse de esta tabla y reemplazarse con la clave de una nueva tabla. El resultado de este esquema se muestra a continuacin: ID_Ciente ID_Direccion Nombre ID_Cliente Apellidos Direccion La base de datos ahora cumple con la Primera Forma Normal. Los clientes pueden tener ms de una direccin. El problema aqu es que usted ha complicado demasiado una idea simple, por tratar de seguir las reglas de normalizacin. En el ejemplo mostrado, la segunda direccin es totalmente opcional. Est ah slo para colectar informacin que pudiera utilizarse como informacin de contacto. No hay necesidad de partir la tabla en dos y forzar las reglas de la normalizacin. En esta instancia, el exceso de normalizacin frustra el propsito para el que se utilizan los datos. Aade, de manera innecesaria, un nivel ms de complejidad. Una buena forma de determinar si est llevando demasiado lejos su normalizacin, es ver el nmero de tablas que tiene. Un nmero grande de tablas pudiera indicar que est normalizando demasiado. Observe su esquema. Est dividiendo tablas slo para seguir las reglas o estas divisiones son en verdad prcticas? stas son el tipo de cosas que usted, el diseador de la base de datos, necesita decidir. La experiencia y el sentido comn lo pueden auxiliar para tomar la decisin correcta. La normalizacin no es una ciencia exacta. Es subjetiva. Existen seis niveles ms de normalizacin que no se han discutido aqu. Ellos son Forma Normal Boyce-Codd, Cuarta Forma Normal (4NF), Quinta Forma Normal (5NF) o

Forma Normal de Proyeccin-Unin, Forma Normal de Proyeccin-Unin Fuerte, Forma Normal de Proyeccin-Unin Extra Fuerte y Forma Normal de Clave de Dominio. Estas formas de normalizacin pueden llevar las cosas ms all de lo que necesita. stas existen para hacer una base de datos realmente relacional. Tienen que ver principalmente con dependencias mltiples y claves relacionales. En resumen La normalizacin es una tcnica que se utiliza para crear relaciones lgicas apropiadas entre tablas de una base de datos. Ayuda a prevenir errores lgicos en la manipulacin de datos. La normalizacin facilita tambin agregar nuevas columnas sin romper el esquema actual ni las relaciones. Existen varios niveles de normalizacin: Primera Forma Normal, Segunda Forma Normal, Tercera Forma Normal, Forma Normal Boyce-Codd, Cuarta Forma Normal, Quinta Forma Normal o Forma Normal de Proyeccin-Unin, Forma Normal de Proyeccin-Unin Fuerte, Forma Normal de Proyeccin-Unin Extra Fuerte y Forma Normal de Clave de Dominio. Cada nuevo nivel o forma lo acerca ms a hacer su base de datos verdaderamente relacional. Se discutieron las primeras tres formas. stas proveen suficiente nivel de normalizacin para cumplir con las necesidades de la mayora de las bases de datos. Normalizar demasiado puede conducir a tener una base de datos ineficiente y hacer a su esquema demasiado complejo para trabajar. Un balance apropiado de sentido comn y prctico puede ayudarle a decidir cundo normalizar.

Xxxxxxxxxxxxxxxxxxxxxxx

Diseo de las tablas

Una vez realizado este estudio llega el momento de crear las tablas, para ello colocaremos en cada tabla aquellos campos del tipo Nuevo, teniendo cuidado de que en cada tabla no haya ningn campo que se repita. Por ejemplo, en la tabla de pedidos no colocaremos el cdigo del producto ya que en un pedido puede haber varios productos, para solucionar esto crearemos una tabla auxiliar que llamaremos Detalles de pedidos, en la que incluiremos los campos: clave del producto, PrecioUnidad, Cantidad y Descuento. En nuestro ejemplo llegamos a la conclusin de que son necesarias seis tablas Tabla Clientes Tamao

Nombre IdCliente NombreCompaa NombreContacto CargoContacto Direccin Ciudad

Tipo

Otras propiedades clave

Regin CdPostal Pas Telfono Fax

Tabla Compaas de envos Nombre Tipo Tamao Otras propiedades IdCompaaEnvos clave NombreCompaa Telfono

Nombre IdPedido IdProducto PrecioUnidad Cantidad Descuento

Tabla Detalles de pedidos Tipo Tamao

Otras propiedades clave clave

Nombre IdEmpleado Apellidos Nombre Cargo Tratamiento FechaNacimiento FechaContratacin Direccin Ciudad Regin CdPostal

Tipo

Tabla Empleados Tamao

Otras propiedades clave

Pas TelDomicilio Extensin Foto Notas Jefe

Nombre Tipo IdPedido IdCliente IdEmpleado FechaPedido FechaEntrega FechaEnvo FormaEnvo Cargo Destinatario DireccinDestinatario CiudadDestinatario ReginDestinatario CdPostalDestinatario PasDestinatario

Tabla Pedidos Tamao

Otras propiedades clave

Nombre Tipo IdProducto NombreProducto CantidadPorUnidad PrecioUnidad

Tabla Productos Tamao

Otras propiedades clave

Mtodo de dependencias funcionales

A continuacin vamos a ver un mtodo mecnico para disear las tablas de la base de datos (normalizar). Recordemos la definicin tcnica de dependencia funcional: dados dos campos, A y B, se dice que B es funcionalmente dependiente de A si para cada valor de A existe un nico valor de B, asociado con l. Empezamos tomando aquellos campos que de una manera clara sern claves en alguna tabla como por ejemplo el Idcliente. Para saber si un campo depende funcionalmente de otro nos hacemos el siguiente razonamiento: Si conozco el Idcliente, existe un nico apellido del cliente asociado a el?, SI, luego los apellidos dependen funcionalmente del campo Idcliente. (Idcliente apellidos ) Si conozco el IdPedido existe un nico Producto en el pedido asociado a el?, NO, ya que un pedido puede no tener un nico producto, por lo tanto el producto no depende funcionalmente de IdPedido. IdEmpleado Nombre Obtencin de todas las dependencias funcionales

IdEmpleado Apellidos IdEmpleado Cargo IdEmpleado TratamientoEmp IdEmpleado FechaNacimiento IdEmpleado FechaContratacin IdEmpleado Direccin IdEmpleado Ciudad

IdEmpleado Regin IdEmpleado CdPostal IdEmpleado Pas IdEmpleado TelDomicilio IdEmpleado Extensin IdEmpleado Foto IdEmpleado Notas IdEmpleado Jefe IdPedido, IdProducto PrecioUnidadNotar que en el caso del PrecioVenta de un producto este depende a la vez del IdProducto y del IdPedido, es decir va a tener una clave doble. Esta relacin contiene todas las dependencias funcionales que yo he visto, aunque posiblemente podran determinarse mas de las que aqu aparecen. A partir de ahora se trata de simplificar hasta lograr una cobertura mnima, es decir que un campo no puede depender funcionalmente mas que de una clave. Para realizar el proceso de simplificar, nos basaremos en la siguiente propiedad: Si tenemos que A B, y B C, se puede deducir la dependencia A C, siendo esta ltima dependencia redundante (sobrante). En nuestro ejemplo tenemos que IdPedido IdEmpleado, y IdEmpleado Nombre, luego la expresin IdPedido Nombre, es redundante y podemos eliminarla. Continuaremos este proceso de simplificacin hasta obtener una cobertura mnima en la que aparezcan todos los campos una sola vez. Simplificacin y obtencin de las tablas

Simplificamos tachando las sobrantes.

IdPedido FechaPedido IdPedido FechaEntrega IdPedido FechaEnvo IdPedido FormaEnvo IdPedido Cargo IdPedido IdCliente IdPedido NombreCompaa IdPedido NombreContacto IdPedido Direccin IdPedido Ciudad IdPedido Regin IdPedido CdPostal IdPedido Pas IdPedido Destinatario IdPedido DireccinDestinatario IdPedido CiudadDestinatario IdPedido, IdProducto PrecioUnidad IdEmpleado Nombre

IdEmpleado IdPedido, IdProducto Apellidos Cantidad IdEmpleado Cargo IdPedido, IdProducto Descuento IdEmpleado TratamientoEmp IdCliente NombreCompaa IdCliente NombreContacto IdCliente CargoContacto IdCliente Direccin IdCliente Ciudad IdCliente Regin IdEmpleado FechaNacimiento IdEmpleado FechaContratacin IdEmpleado Direccin IdEmpleado Ciudad IdEmpleado Regin IdEmpleado CdPostal

IdCliente CdPostal IdEmpleado Pas IdCliente Pas IdCliente Telfono IdCliente Fax IdEmpleado TelDomicilio IdEmpleado Extensin IdEmpleado Foto IdProducto NombreProducto IdProducto IdEmpleado Notas IdEmpleado Jefe

IdPedido ReginDestinatario CantidadPorUnidad IdPedido CdPostalDestinatario IdProducto PrecioUnidad IdPedido PasDestinatario IdPedido NombreProducto IdPedido IdEmpleado IdPedido NombreEmpleado Hacemos limpieza borrando los que se han tachado, y obtenemos las tablas de la base de datos sin mas que definir una tabla por cada conjunto de dependencias funcionales de la misma clave IdCompaaEnvos NombreCompaaEnv os IdCompaaEnvos Telfono

Agrupamos por claves obteniendo las tablas.

xxxxxxxxxxxxxxxxxx

Normalizar una tabla de ejemplo

En los pasos siguientes se demuestra el proceso de normalizacin de una tabla de alumnos ficticia. 1. Tabla unnormalized: Contraer esta tablaAmpliar esta tabla Los Espacio alumnos Asesor Class1 Class2 Class3 de adv # 1022 Jones 412 101 07 143-01 159-02 4123 Smith 216 201-01 211-02 214-01

2. Primera forma normal: no hay repeticin grupos Las tablas deben tener slo dos dimensiones. Como cada alumno est inscrito en varias clases, stas deben aparecer en una tabla independiente. Los campos Clase1, Clase2 y Clase3 de los registros anteriores indican que existe un problema en el diseo. En las hojas de clculo se utiliza con frecuencia la tercera dimensin, pero no debe hacerse en las tablas. Otra forma de ver el problema es considerar una relacin de uno a varios; no se debe poner en la misma tabla el lado en el que hay un elemento y el lado en el que hay varios elementos. En su lugar, crear otra tabla en la primera forma normal, eliminando el grupo de repeticin (clase #), tal y como se muestra a continuacin: Contraer esta tablaAmpliar esta tabla Los alumnos # Asesor Espacio de adv Clase # 1022 Jones 412 101 07 1022 Jones 412 143-01 1022 Jones 412 159-02 4123 Smith 216 201-01 4123 Smith 216 211-02 4123 Smith 216 214-01 3. Segunda forma normal: eliminar datos redundantes Tenga en cuenta los valores de clase # varios para cada valor de los alumnos # en la tabla anterior. Clase # no es funcionalmente depende de los alumnos # (clave principal), por lo que esta relacin no est en la forma en segundo lugar normal. Las dos tablas siguientes muestran la segunda forma normal: Los alumnos

Contraer esta tablaAmpliar esta tabla Los alumnos # Asesor Espacio de adv 1022 Jones 412 4123 Smith 216 Registro Contraer esta tablaAmpliar esta tabla Los alumnos # Clase # 1022 101 07 1022 143-01 1022 159-02 4123 201-01 4123 211-02 4123 214-01 4. Tercera forma normal: eliminar datos no dependientes en clave En el ltimo ejemplo, adv de espacio (nmero de oficina el asesor) depende funcionalmente el atributo asesor. La solucin es mover dicho atributo de la tabla Alumnos a la tabla Personal, como se muestra a continuacin: Los alumnos Contraer esta tablaAmpliar esta tabla Los alumnos # Asesor 1022 Jones 4123 Smith Profesores Contraer esta tablaAmpliar esta tabla Nombre Espacio Departamento Jones 412 42 Smith 216 42 Volver al principio

Referencias Ahlo, Hamilton M., Randy Brown y Peter Colclough. FoxPro 2: Guide A Developer '...
Ahlo, Hamilton M., Randy Brown y Peter Colclough. FoxPro 2: Guide A Developer 'S: experto Gua de programacin de intensidad de industrial . John Wiley & Sons, de 1991 de octubre. Las pginas de 220-225. Callahan, Roger. con Access 1.1 de Windows . Corporation, de 1993 de julio. 799 Las pginas de 800. Volver al principio
La informacin de este artculo se refiere a:

Microsoft Access 2000 Standard Edition

Volver al principio principio automtica IMPORTA NTE: Este artculo ha sido traducido por un software de traduccin automtica de Microsoft (http://supp ort.microsof t.com/gp/mt details) en lugar de un traductor

kbmt kbdatabase TelfonoJua kbdesign n$ 150.000cocine kbinfo ro132 - 46 - kbusage 87Palabras KB209534 clave: KbMtes

humano. Microsoft le ofrece artculos traducidos por un traductor humano y artculos traducidos automtica mente para que tenga acceso en su propio idioma a todos los artculos de nuestra base de conocimient os (Knowledge Base). Sin embargo, los artculos traducidos automtica mente pueden contener errores en el vocabulario, la sintaxis o la gramtica, como los que un extranjero podra cometer al hablar el idioma. Microsoft

no se hace responsable de cualquier imprecisin, error o dao ocasionado por una mala traduccin del contenido o como consecuenci a de su utilizacin por nuestros clientes. Microsoft suele actualizar el software de traduccin frecuenteme nte. Si ve errores y desea ayudar con este esfuerzo, rellene la encuesta en la parte inferior de este artculo. Haga clic aqu para ver el artculo original (en ingls): 209534
Xxxxxxxxxxxxxx

Ejercicios Normalizaci n
1. Una escuela determinada tiene un grupo de dormitorios en donde viven los estudiantes. La escuela tambin tiene varios clubes, y cada estudiante puede pertenecer a uno o ms de estos clubes. Considere las siguientes tablas, que describen la situacin: ESTUDIA NTE_DOR M[ID_EST UDIANTE, DORM, PRECIO_A NUAL_DO RM] ESTUDIA NTE_CLU B[ID_EST UDIANTE, CLUB, PRECIO_A NUAL_CL UB] a) Para cada tabla, indicar 1) la clave; 2) cada dependen

cia funcional; y 3) la Forma normal. b) Transform e cada tabla a su Tercera Forma Normal.

2. Suponga que el diseo de un tipo de entidad CLIENTES incluye informacin relativa a los pedidos, tal como sigue: CLIENTES [ID, NOMBRE, DIRECCIO N, TELEFON O, FECHA_P EDIDO, SABOR, CANTIDA D] Transforme esto en dos tablas relacionales y encuentre las claves adecuadas para las tablas que resulten de la descomposicin.

3. Un grupo de mdicos vive en una pequea ciudad. Cada mdico tiene varios pacientes, pero cada paciente visita nicamente a un mdico. a) Disee una tabla que represente esta situacin, usando nicamente los siguientes atributos: NOMBRE_ DOCTOR DIRECCIO N_DOCTO R TELEFON O_DOCTO R RUT_PACI ENTE NOMBRE_ PACIENTE DIRECCIO N_PACIEN TE TELEFON O_PACIE NTE FECHA_U LTIMA_C ONSULTA

b) Transforme la tabla en una o ms tablas relacionales, cada una de las cuales est al

menos en Tercera Forma Normal. Para cada tabla indique las claves y las dependencias funcionales. 4. Supongamos que, en una ciudad cercana, la situacin es ligeramente diferente de la descrita en el problema anterior: cada mdico tiene varios pacientes, pero cada paciente puede tener varios mdicos a la vez. Usando slo los atributos del problema anterior, redisee la base de datos de tal modo que cada tabla quede al menos en Tercera Forma Normal.

xxxxxxxxxxxxxxx

Vamos a partir de algunos ejemplos los cuales iremos normalizando: Primera forma normal (PFN) La primera forma normal

bsicamente se refiere a la forma que deben tener los registros: mismo nmero de campos y valor atmicos, es decir, eliminar las columnas repetidas y colocarse en tablas separadas. Ejemplo:

En esta entidad se esta violando la PFN porque un cliente puede tener varios telfonos, entonces el valor del campo ya deja de ser atmico, una clsica forma (mala practica) es colocar varios campos indicando diferentes telfonos (telefono1, telefono2, , telfonon) pero esta forma tambin viola la primera forma normal, lo correcto es separar esos campos y colocarlos en tablas diferentes.

Quedara de la siguiente forma:

Segunda forma normal (SFN) Una entidad esta en SFN si esta en PFN y no existe DF cuyo determinante sea un sub-conjunto del identificador y cuyo atributo del lado derecho no forme parte del mismo. En otras palabras, si una parte del identificador determina otros atributos (que no formen parte de el) se viola la SFN. Esto solamente tiene sentido cuando un identificador esta compuesto. Ejemplo:

En esta entidad se esta violando la SFN porque existe un DF en los atributos nombre_proveedo r y direccion_provee

dor. Aplicando la regla de la SFN procedemos a eliminar la DF y nuestro esquema quedara de la siguiente forma:

Tercera forma normal (TFN) Una entidad esta en TFN si esta en SFN y no existe DF entre atributos que no formen parte del identificador, es decir que un atributo haga referencia a otro atributo sin que este forme parte del identificador. Ejemplo:

En esta entidad se esta violando la TFN porque el atributo ciudad_de_nacimi ento hace referencia al atributo numero_de_habit antes siendo que ciudad_de_nacimi ento no es el identificador de

esa entidad. Siguiendo la TFN el esquema quedara as:

Conclusin La normalizacin es una herramienta para validar la calidad del esquema y no un mtodo para disear el esquema, en el primer enfoque se utilizan mecanismos de abstraccin para captar los requerimientos del dominio de aplicaciones, mientras que en el segundo caso se utilizan las DF. Estos dos enfoques son opuestos, ahora bien, lo valioso del primero es que de una manera natural se tiende a producir esquemas normalizados esto se debe a que los conceptos no se mezclan, si no que se separan adecuadamente

gracias al uso de la clasificacin, la agregacin y la generalizacin. Las violaciones a las formas normales bsicamente obedecen finalmente a malos diseos lo cual es precisamente lo que la metodologa trata de evitar. Entonces el hecho de utilizar a la normalizacin como una herramienta de validacin es congruente con sus principios.
Xxxxxxxxxxxxxxxx

Mira, la primera forma normal te dice que los datos deben ser atmicos, quiere decir esto que no pueden dividirse, por ejemplo: Un dato supongamos, nombre de una persona: el nombre est compuesto por nombre+apellido

paterno+apellido materno, por lo tanto, para que est en 1FN deberas tener 3 campos, uno para el nombre, otro para el paterno y otro para el materno(claro que todo depende del contexto, pero es un ejemplo). Otro ejemplo sera el nmero telfonico, una persona puede tener un slo nmero de telfono, o tamben puede tener varios (o ninguno), por lo tanto, si el numero telefnico no es nico, se debe convertir en una tabla, y as tienes: Tabla original (persona) codigo, nombre, telefono Despues de la primera normalizacin obtienes dos tablas: Tabla persona: codigo, nombre, paterno, materno

Tabla telefonos: codigo(persona), numero Y una relacin: persona->telefono (1,N) Tambin te dice que los datos repetidos se eliminan. Esto significa que si tu tabla es por ejemplo: Ventas cliente, item, boleta, producto, cantidad, total Y tienes los datos: pepe, 1, 001, pan, 5, 20 pepe, 2, 001, leche, 3, 100 pepe, 3, 001, azucar, 1, 12 Si notas la primera y tercera columna, tienen losmismos valores (pepe y 001) por lo tanto, eso te indica que esos campos probablemente no deben ir all, y deben ir en otras tablas tabla cliente:

codigo, nombre tabla boleta: numero tabla detalle: codigo(cliente), item, numero(boleta), cantidad, total Y asi sucesivamente, hasta que los datos dejen de repetirse en la misma tabla (claro que nunca lo logras porque siempre va a repetirse alguno pero basicamente lo que se evita es que se repitan datos innecesarios como el nombre dle cliente, el cual no tiene porque estarse repitiendo tantas veces) La segunda se aplica en llaves compuestas y se utiliza para decidir si un campo pertenece a una tabla o pertenece a otra, por ejemplo: Tabla venta (ejemplo, una boleta o factura de venta)

--------------------------------------------item, boleta, producto, cantidad, total Claves: item y boleta. Debemos averiguar si los otros tres campos pertenecen a la tabla venta o pertenecen a otra tabla, para eso analizamos cada campo: El producto es dependiente del item y de la boleta? Es decir, para que el producto exista, debe existir la boleta. La respuesta es No porque el producto es independiente de la boleta, por lo tanto el producto sale hacia otra tabla La cantidad es dependiente? Si, porque cuando haces una venta, vendes una cantidad determinada, la cual unicamente se puede saber

cuando se efectue la venta (por dcir, se venden 3 botellas de X producto, o 5 unidades de Z, etc). Entonces, el campo cantidad se queda. Y el total tambien es dependiente porque se calcula a partir de la cantidad y si la cantidad es dependiente es facil saber que el total es dependiente Por lo tanto me quedan dos tablas: tabla producto: codigo, nombre, tabla venta: item. boleta, codigo(producto), cantidad, total Y otra relacin: producto->venta (1,N) Espero te ayude a comprender, obviamente para poder aprender a hacer normalizacin debes partir desde una ficha de datos

mezclados obtenidos a partir de alguna investigacin, por ejemplo los datos de las ventas diarias de alguna entidad X (como en el ejemplo), donde lo nico que conoces es: Ventas Diarias: cliente, direccion, documento, boleta, producto, cantdiad, total, descuento, pago, tarjeta, ... Todos son datos que a primera vista no tienen mucha relacin, y desde all partes a normalizar, para encontrarles la relacin, guindote de las formas normales. Xxxxxxxxxxxxxx xxxx

PARTE VI NOR MAL

IZAC IN DE LAS TAB LAS DE UNA BAS E DE DAT OS

Tablas
Las tablas en una base de datos, son las estructuras donde se guardan los datos, estas estructuras se basan en las entidades que se extraen de la realidad, cuando se hace el anlisis del problema al

que se le quiere dar solucin por un sistema informtico. La siguiente es una tabla con tres registros, que representa una entidad llamada empleado y que tiene cuatro atributos.

Nombre
JorgeSalario

Cargo
Ana

$ 110.000ayudante cocina $ 100.000mesera

512 - 47 - 84 321 - 45 - 42

Normalizacin de las tablas

La normalizacin es un proceso en el que se toman los atributos de una entidad y se decide qu hacer con ellos, para hacer un diseo donde no se dupliquen registros, donde se minimice el uso de la memoria de la mquina, se maximice la velocidad en las bsquedas de datos entre otros. A los pasos de este proceso se les conoce como formas normales

El proceso es difcil de entender al principio, puede tener tres o cinco pasos dependiendo del autor, es largo, con prctica y experiencia llega un momento en que no se utiliza, porque el diseador de la base de datos llega al resultado final sin necesidad de hacer todo el proceso. Por eso llega un momento en que los programadores no lo usan y se brincan todos los pasos llegando tambin a un resultado similar o mejor al que se llegara siguiendo todo el proceso. Vamos a utilizar nicamente las tres primeras formas normales, para el proceso las aplicamos en la factura del ejemplo visto en el tema pasado.

Se quiere sistematizar el almacenamiento de la factura y para eso necesitamos un ejemplo de una factura real.

Antes de aplicar las formas normales a la factura, debemos extraer los atributos y hacer una lista con estos. El primer atributo que vemos en la parte superior es el nombre del restaurante, debajo el nmero de factura, luego los productos pedidos (Una lista de otras entidades) a lo que vamos a llamar detalle y por ltimo el total de la factura, hagamos una lista de los atributos encontrados

Factura:

Nombre Restaurante Nmero Factura Detalle Total

Lo que hicimos fue crear una representacin de la entidad Factura, le dimos sus atributos y podemos hacer ahora con estos datos una tabla en la base de datos. Pero cmo hago para guardar muchos productos en un solo atributo (detalle) que tiene la tabla? Cmo hago para que no se repitan las facturas? Estos y otros problemas se resuelven siguiendo el proceso de la normalizacin.

Primer forma normal:

Se dice que una tabla est en primera forma normal si garantiza que cada registro sea nico.

Para hacer esto debemos seleccionar de los atributos disponibles un atributo que nunca se repita, si no existe un atributo con esta caracterstica lo agregamos, este atributo que hace a cada registro nico se le llama (clave principal). En este caso tenemos un atributo que sirve para tal propsito, es el nmero de factura, lo sealamos como clave principal y listo.

Factura: (Primera forma normal)

Nombre Restaurante Nmero Factura Detalle Total

IdPedido, IdProducto Cantidad IdPedido, IdProducto Descuento

IdCliente NombreCompaa IdCliente NombreContacto IdCliente CargoContacto IdCliente Direccin IdCliente Ciudad IdCliente Regin IdCliente CdPostal IdCliente Pas IdCliente Telfono IdCliente Fax

IdProducto NombreProducto IdProducto CantidadPorUnidad IdProducto PrecioUnidad

IdCompaaEnvos NombreCompaaEnvos IdCompaaEnvos Telfono

Escribimos todas las dependencias funcionales.

IdPedido FechaPedido IdPedido FechaEntrega IdPedido FechaEnvo IdPedido FormaEnvo IdPedido Cargo IdPedido IdCliente IdPedido NombreCompaa IdPedido NombreContacto IdPedido Direccin IdPedido Ciudad IdPedido Regin IdPedido CdPostal

IdPedido Pas IdPedido Destinatario IdPedido DireccinDestinatario IdPedido CiudadDestinatario IdPedido ReginDestinatario IdPedido CdPostalDestinatario IdPedido PasDestinatario IdPedido NombreProducto IdPedido IdEmpleado IdPedido NombreEmpleado