11 febrero 2007

Diseñando tablas chidas

Guardar datos tiene su chiste. Especialmente cuando usamos bases de datos relacionales (RDBMS). Voy a explicar un poco de este arte (porque de tu arte al mio...).

Los datos se almacenan en estructuras que llamamos tablas. El buen funcionamiento de un DBMS depende en gran medida en el diseño de las tablas. Para que funcionen bien, es necesario dividir mis datos en diferentes tablas y al proceso de hacer este relajo se le llama normalización.

Normalización es un conjunto de reglas que sirven para ayudar a los diseñadores a desarrollar un esquema que minimice los problemas de lógica. La normalización se adoptó porque el poner todos los datos en un solo lugar, como un archivo o una tabla de la base de datos, era ineficiente y conducía a errores de lógica cuando se trataba de manipular los datos. Por ejemplo, aquí está la base de datos de una tienda que almacena clientes:


Como ves, sería un desgarriate agregar un nuevo cliente a esta tabla porque debería añadirle un producto y un pedido. También sería un relajo hacer un reporte de los productos que vende.

La idea de la normalización es de hacer que las cosas sean fáciles de entender. Tendemos siempre a simplificar las cosas al máximo. Las reglas de la normalización nos sirven para simplificar tablas. En esta tabla, hay 3 diferentes grupos: clientes, productos y pedidos.

Siendo exactos, hay 5 niveles de normalización, pero la base de datos está normalizada con llegar al tercer nivel. La idea es dejar todo hasta la tercera forma normal (o 3NF como lo abreviaría uno que otro jalado).

Primera Forma Normal (1NF para los que les gustan las abreviaturas). La regla aquí es que las columnas repetidas se tienen que eliminar y poner en tablas separadas. En nuestro ejemplo, alteraríamos nuestra tabla Clientes.

Como puedes darte cuenta, esta tabla tiene varias columnas repetidas, las cuales se refieren a los productos. Según esta regla, se deben eliminar (újule: de pronto me sentí como El Padrino, jefe de la mafia) las columnas repetidas y ponerlas en su propia tabla. Debería quedar algo así:


Parece que todo va bien, pero todavía le falta. La bronca es que no hay manera de relacionar ambas tablas: necesitan algún campo común. Para lograr esto, debemos insertar un campo que sea la llave (o índice) para establecer una relación. Para esto, agrega un campo que sea llave primaria llamada ID_Producto en la tabla de Productos y agrega otro campo ID_Producto a la tabla Clientes para relacionarla con la tabla Productos.

Quedaría así:


Y así podemos decir que estas tablas están en la primera forma normal. Si te fijas, hemos establecido una relación uno a varios, es decir, el cliente tendrá muchos productos que pueda comprar, sin importar cuantos otros clientes quieran comprarlos también. Además no es necesario agregar un cliente para tener un nuevo producto.

Segunda Forma Normal (o 2NF). La onda aquí es que esta forma dice que todas las dependencias parciales, o sea todos los datos que no dependen de la clave de la tabla para su identificación, se deben eliminar y separar dentro de sus propias tablas. En nuestro ejemplo, la información de los pedidos está en cada uno de los registros de la tabla Clientes. Sería mucho más simple usar solo el número de pedido y poner el resto de la información en su propia tabla. Quedaría algo así:


Así está mejor la cosa. Ahora puedes agregar nuevas columnas a la tabla Clientes sin afectar las tablas Productos y Pedidos. Lo mismo aplica para las otras tablas. Viendo la tabla Clientes más a fondo, puedes ver que el campo no depende del cliente. Vamos a resolver esto en la 3NF.

Tercera Forma Normal (o 3NF). La regla de esta forma normal es que hay que eliminar y separar cualquier otro dato que no sea clave, o sea que todos los valores de las columnas deben identificarse únicamente por la clave. En nuestro ejemplo chipocles, vemos que existe un campo Nombre_Cia_Envios en la tabla Clientes que no se identifica únicamente por la clave. Vamos a separarlo y ponerlo en otra tabla. Quedaría más o menos así:


Y ya. Está en la 3NF y podemos ser felices. Si te fijas esta distribución te da más flexibilidad y te previene de tener errores de lógica al insertar o eliminar registros. Cada columna en las tablas está identificada solamente por su llave y no hay datos repetidos. Esto hace que sea fácil trabajar con la base de datos y expandirlo.

4 comentarios:

Rocio Baez dijo...

hola estimado, pero corrigeme si me ekivoco.....dices q un cliente puede tener uno o varios pedido, no?? bacan....pero ahi tu poner el numero de pedido como campo de cliente y a la para ahi tmb esta su nombre, su direccion, o sea sus datos.......estos registro se vava a rpetir cuantas pedidos tenga, o sea se va a repetir data innecsaria (nombre, direccion)....es mi duda o esta bien lo q hiciste.q alguien nos corriga

Rocio Baez dijo...

Creo q deberia crear una especie de tabla fact y ahi poner los pk's (una especie de clave compuesta)...

Tony Valderrama dijo...

¡Tienes toda la razón del mundo! No me había fijado.

Tendríamos que hacer los sigientes cambios:

A la tabla Clientes hay que eliminar el campo Numero_Pedido (que no nos va a servir para nada) y crear otra tabla, que voy a llamar ClientePedido, que tenga 2 campos:
ID_Cliente y Numero_Pedido. La llave primaria estaría compuesta por estos dos campos.

Gracias por la observación. ¡Saludos!

Sophie dijo...

nooooo y yo que queria la 4ta y 5ta forma T-T buaaaaaaaaaaaa... como quiera bua explicación ^^

El Tony y sus ondas...

Related Posts Plugin for WordPress, Blogger...