You are on page 1of 4

Jerez Nancy 4TO “C” INGENIERÍA EN SISTEMA

NORMALIZACIÓN DE BASES DE DATOS
Para otros usos de este término, véase Normalización (desambiguación). El proceso de normalización de bases de datos consiste en aplicar una serie de reglas a las relaciones obtenidas tras el paso del modelo entidad-relación al modelo relacional. Las bases de datos relacionales se normalizan para:
  

Evitar la redundancia de los datos. Evitar problemas de actualización de los datos en las tablas. Proteger la integridad de los datos.

En el modelo relacional es frecuente llamar tabla a una relación, aunque para que una tabla sea considerada como una relación 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.

TIPOS DE NORMALIZACIÓN
Existen 3 niveles de Normalización que deben respetarse para poder decir que nuestra Base de Datos, se encuentra NORMALIZADA, es decir, que cumple con los requisitos naturales para funcionar óptimamente y no perjudicar las Performance por mala arquitectura. Estas 3 reglas de Normalización se las conoce como las 3 FORMAS NORMALES. La Primera Forma Normal Esta primera Forma Normal, nos lleva a no repetir datos en nuestras tablas. Los famosos maestro – detalle, deben aplicarse a la estructura de la tabla. Si nuestra tabla de ventas repite una y otra vez (por cada venta), el nombre, el domicilio y otros datos del Cliente, es que no hemos aplicado esta Normalización. Si tenemos una tabla clientes, en la tabla ventas, solo debería figurar el código del cliente, para que el resto de los datos se puedan referenciar automáticamente sin problemas y sin duplicar información. Lo mismo ocurriría en una tabla de detalle de ventas, si por cada item vendido colocamos el detalle del producto, con su descripción , medidas, etc…Tendríamos un desaprovechamiento de espacio y recursos muy grande. Para ello, tendremos nuestra tabla maestra de Productos y con solo grabar el código de dicho producto en nuestra tabla de ventas, será suficiente.

. Es por ello que proponemos el siguiente esquema VentaID 1 1 1 1 2 ItemID 1 2 3 4 1 ProductoId 2334 3333 66643 21 3566 Cantidad 10 2 34 3 6 Y ahora nuestra nueva tabla maestra VentaId 1 2 FechaVenta 01/12/2007 02/12/2007 ClienteVenta 2 5 Entonces. si tuviéramos alguna columna que se repite a lo largo de todos los registros. Pero supongamos un ejemplo donde ciertas columnas no dependen de la clave principal y si dependen de una columna de nuestra tabla. La Tercera Forma Normal En realidad si nos guiamos en el ejemplo de esta nota. Esto significa que todo un registro debe depender únicamente de la clave principal. ya no quedaría normalización por aplicar y podríamos decir que nuestro ejemplo cumple con las 3 formas normales. Veamos un ejemplo VentaID 1 1 1 1 2 ItemID 1 2 3 4 1 FechaVenta 01/12/2007 01/12/2007 01/12/2007 01/12/2007 02/12/2007 ClienteVenta 2 2 2 2 5 ProductoId 2334 3333 66643 21 3566 Cantidad 10 2 34 3 6 Ahí tenemos un claro problema!!! Acaso no se busca NO REPETIR DATOS ?Si toda una venta tendrá el mismo número de Cliente y la misma Fecha… Por qué no crear una Tabla de MAESTRO DE VENTAS y que contenga esos 2 datos. ya que la 3ra Forma Normal nos habla de que: 1. nuestra 2da Forma Normal nos habla de que cada columna de una tabla debe depender de toda la clave y no constituir un dato único para cada grupo de registros. Ninguna Columna puede depender de una columna que no tenga una clave 2. No puede haber datos derivados En el 2do ejemplo hemos descubierto campos que dependían de la clave principal (VentaID) y que podrían incluirse en una tabla maestra. Es evidente que la columna ClienteVenta y Fecha Venta se repetirán por cada venta realizada. dichos datos deberían atomizarse en una nueva tabla.Jerez Nancy 4TO “C” INGENIERÍA EN SISTEMA La Segunda Forma Normal (Si o si debe estar previamente aplicada la Primera Forma Normal) La Segunda Forma Normal nos habla de que cada columna de la tabla debe depender de la clave.

esta información podría derivarse de los datos persistentes. pero no se le considera en si como parte de la Base de Datos.Jerez Nancy 4TO “C” INGENIERÍA EN SISTEMA VentaI D 1 1 2 ItemID 1 2 1 ProductoID 3455 2455 5444 Cantidad 12 34 21 Descripcion Medida Proveedor 1 1 1 Impresora 122cm HP LJ8000 Scanner 33cm HP A3555 Mouse HP Wireless Esto es muy normal encontrar en bases mal normalizadas. pero en principio no forma parte de la base de datos propiamente dicha. Tipos de Datos Los Tipos de Datos de una Base se dividen en dos estas son:  Las de Entrada Se refiere a la información que entra al sistema por primera vez. Conclusión Finalmente si tomamos en cuenta que una tabla de detalle de venta (item x item) puede contener un volumen de millones de registros. Vemos que los campos DESCRIPCIÓN. Esta información podría dar pie a una modificación de los datos persistentes. ya que dependen de PRODUCTOID. al haberle aplicado las 3 formas normales nos estaremos ahorrando varios Gigabytes de tamaño en dicha tabla y por supuesto mejorado notablemente la performance. Una vez más. MEDIDA y PROVEEDOR no dependen de VENTAID y es por ello que no deberían estar dentro de la tabla de detalle de ventas. . Aquí no se trata ya de eliminar grupos repedidos de datos (1ra Forma Normal) sino que ante la inclusión de una clave perteneciente a otra tabla.  Las de Salida Se refiere a mensajes y resultados que emanan del sistema. cualquier campo que sea subordinado de dicha clave debe estar en otra tabla y no en nuestra tabla detalle.

685.402823*1038 a 1.147.5807. SINGLE 4 bytes Un valor en punto flotante de precisión simple con un rango de -3.483. SHORT 2 bytes Un entero corto entre -32. LONGTEXT 1 byte por De cero a un máximo de 1.337. LONG 4 bytes Un entero largo entre -2.477. Utilizado para objetos necesite OLE. y 0.79769313486232*10308 a -4.483. 1.203.648 y 2. DATETIME 8 bytes Un valor de fecha u hora entre los años 100 y 9999.477.401298*10-45 para valores negativos.79769313486232*10 para valores positivos.767.647. 4. DOUBLE 8 bytes Un valor en punto flotante de doble precisión con un rango de -1.94065645841247*10-324 para valores negativos.203.2 gigabytes.768 y 32.402823*1038 para valores positivos. carácter LONGBYNARY Según se De cero 1 gigabyte.337. BIT 1 byte Valores Si/No ó True/False BYTE 1 byte Un valor entero entre 0 y 255.685.147. y 0.94065645841247*10-324 a 308 1. TEXT 1 byte por De cero a 255 caracteres. caracter .Jerez Nancy 4TO “C” INGENIERÍA EN SISTEMA Tipos de datos primarios: Tipo de Datos BINARY Longitud 1 byte Descripción Para consultas sobre tabla adjunta de productos de bases de datos que definen un tipo de datos Binario. COUNTER 4 bytes Un número incrementado automáticamente (de tipo Long) CURRENCY 8 bytes Un entero escalable entre 922.401298*10-45 a 3.5808 y 922.