Listado y descripción de los distintos tipos de datos de MySQL.MySQL soporta varios tipos de datos, que pueden ser agrupados en tres categorías: numéricos, fecha y hora, y cadenas (caracteres). En este trabajo se presenta un breve resumen de estos tipos, se mencionan sus requerimientos de almacenamiento, y se hace una descripción más detallada de las propiedades de cada uno de ellos. Los tipos de datos soportados por MySQL son listados a continuación. Las siguientes convenciones son usadas en las descripciones: M - Indica el tamaño máximo que se puede desplegar (mostrar). El mayor valor legal es de 255. D - Aplica a los datos de punto flotante e indica el número de digitos que siguen al punto decimal. El valor máximo posible es de 30, pero no debe ser mayor de M-2. Los paréntesis cuadrados indican que un elemento es opcional. Se debe notar que cuando se especifica ZEROFILL para una columna, MySQL agregará automáticamente el atributo UNSIGNED. Los tipos de datos que puede haber en un campo, se pueden agrupar en tres grandes grupos: • Tipos numéricos: Existen tipos de datos numéricos, que se pueden dividir en dos grandes grupos, los que están en coma flotante (con decimales) y los que no. TinyInt: es un número entero con o sin signo. Con signo el rango de valores válidos va desde -128 a 127. Sin signo, el rango de valores es de 0 a 255 Bit ó Bool: un número entero que puede ser 0 ó 1 SmallInt: número entero con o sin signo. Con signo el rango de valores va desde -32768 a 32767. Sin signo, el rango de valores es de 0 a 65535. MediumInt: número entero con o sin signo. Con signo el rango de valores va desde -8.388.608 a 8.388.607. Sin signo el rango va desde 0 a16777215. Integer, Int: número entero con o sin signo. Con signo el rango de valores va desde -2147483648 a 2147483647. Sin signo el rango va desde 0 a 429.4967.295 BigInt: número entero con o sin signo. Con signo el rango de valores va desde -9.223.372.036.854.775.808 a 9.223.372.036.854.775.807. Sin signo el rango va desde 0 a 18.446.744.073.709.551.615. Float: número pequeño en coma flotante de precisión simple. Los valores válidos van desde -3.402823466E+38 a -1.175494351E-38, 0 y desde 1.175494351E-38 a 3.402823466E+38. xReal, Double: número en coma flotante de precisión doble. Los valores permitidos van desde -1.7976931348623157E+308 a -2.2250738585072014E308, 0 y desde 2.2250738585072014E-308 a 1.7976931348623157E+308 Decimal, Dec, Numeric: Número en coma flotante desempaquetado. El número se almacena como una cadena Tipo de Campo TINYINT SMALLINT MEDIUMINT INT INTEGER BIGINT FLOAT(X) FLOAT DOUBLE DOUBLE PRECISION REAL Tamaño de Almacenamiento 1 byte 2 bytes 3 bytes 4 bytes 4 bytes 8 bytes 4 ú 8 bytes 4 bytes 8 bytes 8 bytes 8 bytes M+2 bytes sí D > DECIMAL(M,D 0, M+1 bytes sí D =0 M+2 bytes if D > NUMERIC(M,D) 0, M+1 bytes if D =0 • NUMERIC y DECIMAL son implementados como el mismo tipo por MySQL, tal como lo permite el estándar SQL92. Estos tipos son usados para valores en los cuales es importante preservar la precisión exacta, por ejemplo con datos monetarios. Cuando se declara una columna de uno de estos tipos la precisión y la escala pueden ser especificados; por ejemplo: salario DECIMAL(5,2) En este ejemplo, 5 (precisión) representa el número de digitos significativos que serán almacenados para los valores, y 2 (escala) representa el número de digitos que serán almacenados a continuación del punto decimal. En este caso, el rango de valores que pueden ser almacenados en la columna salario es de -999.99 a 999.99. (Cabe señalar que MySQL puede almacenar números hasta 9999.99 en esta columna ya que no se almacena el signo para los números positivos). • Tipos fecha: A la hora de almacenar fechas, hay que tener en cuenta que Mysql no comprueba de una manera estricta si una fecha es válida o no. Simplemente comprueba que el mes está comprendido entre 0 y 12 y que el día está comprendido entre 0 y 31. Date: tipo fecha, almacena una fecha. El rango de valores va desde el 1 de enero del 1001 al 31 de diciembre de 9999. El formato de almacenamiento es de añomes-dia DateTime: Combinación de fecha y hora. El rango de valores va desde el 1 de enero del 1001 a las 0 horas, 0 minutos y 0 segundos al 31 de diciembre del 9999 a las 23 horas, 59 minutos y 59 segundos. El formato de almacenamiento es de año-mes-día horas: minutos: segundos. TimeStamp: Combinación de fecha y hora. El rango va desde el 1 de enero de 1970 al año 2037. El formato de almacenamiento depende del tamaño del campo: Tamaño Formato 14 12 8 6 AñoMesDiaHoraMinutoSegundo aaaammddhhmmss AñoMesDiaHoraMinutoSegundo aammddhhmmss ñoMesDia aaaammdd AñoMesDia aammdd 4 2 AñoMes aamm Año aa Time: almacena una hora. El rango de horas va desde -838 horas, 59 minutos y 59 segundos a 838, 59 minutos y 59 segundos. El formato de almacenamiento es de 'HH:MM:SS' Year: almacena un año. El rango de valores permitidos va desde el año 1901 al año 2155. El campo puede tener tamaño dos o tamaño 4 dependiendo de si queremos almacenar el año con dos o cuatro dígitos. Tipo Campo DATE DATETIME TIME YEAR de Tamaño de Almacenamiento 3 bytes 8 bytes 3 bytes 1 byte TIMESTAMP 4 bytes • MySQL regresa valores para un tipo de fecha y hora determinado en un formato estándar, pero trata de interpretar una cierta variedad de formatos de valores que se le aporten (por ejemplo, como cuando especificamos un valor que debe ser asignado o comparado a un tipo fecha/hora). Aún así, sólo los formatos especificados en las próximas secciones son soportados. Se espera que se proporcionen valores legales, y que los resultados impredecibles ocurran en el caso de utilizar fechas con otros formatos. A pesar de que MySQL trata de interpretar valores en varios formatos, siempre espera que el año sea el valor más a la izquierda. Las fechas han de ser proporcionadas en el orden año-mes-día (por ejemplo 98-09-04), en vez de mesdía-año o día-mes-año, utilizados comúnmente en algunas aplicaciones (ejemplos: 09-04-98, 04-09-98). MySQL convierte automáticamente un tipo de fecha y hora a un número si el valor es utilizado en un contexto numérico, y vice-versa. Cuando MySQL encuentra un valor para un tipo de fecha y hora que se encuentra fuera del rango o en cualquier caso que su valor es ilegal para el tipo, MySQL convierte el valor al "cero" correspondiente al tipo. (La excepción es que los valores de tipo TIME que están fuera de rango se ajustan al límite máximo del rango de TIME). La tabla siguiente presenta el formato del valor "cero" de cada tipo: • • • Tipo de dato DATETIME DATE TIMESTAMP TIME YEAR Valor "cero" '0000-00-00 00:00:00' '0000-00-00' 00000000000000(la longitud depende del tamaño de despligue) '00:00:00' 0000 • El valor "cero" es especial, pero podemos almacenar o referirnos a el explícitamente utilizando los valores presentados en la tabla. También podemos hacerlo utilizando los valores '0' o 0, que son más sencillos de escribir. Los valores de fecha u hora "cero" utilizados a través de MyODBC son convertidos automáticamente a NULL en las versiones 2.50.12 y superiores de MyODBC, ya que ODBC no puede manejar tales valores. • • Tipos de cadena: Char(n): almacena una cadena de longitud fija. La cadena podrá contener desde 0 a 255 caracteres. VarChar(n): almacena una cadena de longitud variable. La cadena podrá contener desde 0 a 255 caracteres. Dentro de los tipos de cadena se pueden distinguir otros dos subtipos, los tipo Test y los tipo BLOB (Binary large Object) La diferencia entre un tipo y otro es el tratamiento que reciben a la hora de realizar ordenamientos y comparaciones. Mientras que el tipo test se ordena sin tener en cuenta las Mayúsculas y las minúsculas, el tipo BLOB se ordena teniéndolas en cuenta. Los tipos BLOB se utilizan para almacenar datos binarios como pueden ser ficheros. TinyText y TinyBlob: Columna con una longitud máxima de 255 caracteres. Blob y Text: un texto con un máximo de 65535 caracteres. • En la mayoría de casos, podemos entender el tipo TEXT como un tipo VARCHAR en el que su longitud es tan grande como se quiera. De un modo similar, podemos entender el tipo BLOB como un VARCHAR BINARY con menos restricciones de espacio. Las diferencias son que: 1. Se pueden tener índices en campos BLOB y TEXT con la versión MySQL 3.23.2 y posteriores. Las versiones más antiguas de MySQL no lo soportan. 2. No se eliminan los espacios sobrantes en los tipos BLOB y TEXT al almacenar los datos, como se hace en los campos VARCHAR. 3. Las columnas BLOB y TEXT no pueden tener valores por defecto. MyODBC define los valores BLOB como LONGVARBINARY y los valores TEXT como LONGVARCHAR. Debido a que los valores BLOB y TEXT pueden ser muy grandes, se pueden tener ciertas restricciones al utilizarlos: • Si se quieren utilizar las cláusulas GROUP BY o ORDER BY en campos TEXT y BLOB, se debe convertir el valor de la columna en un objeto de longitud fija. La forma estándar de hacerlo es con la función SUBSTRING. Por ejemplo: mysql> SELECT comment FROM tbl_name, SUBSTRING(comment,20) AS substr ORDER BY substr; • Si no se hace, sólo los primeros max_sort_length bytes de la columna serán utilizados al ordenar. El valor por defecto de max_sort_length es de 1024; este valor puede ser modificado usando la opción –O al iniciar el servidor MySQL. Se pueden agrupar en una expresión que incluya valores BLOB y TEXT especificando la posición de la columna o utilizando un alias: mysql> SELECT id,SUBSTRING(blob_col,1,100) FROM tbl_name GROUP BY 2; mysql> SELECT id,SUBSTRING(blob_col,1,100) AS b FROM tbl_name GROUP BY b; • El tamaño máximo de un objeto BLOB o TEXT es determinado por el tipo, pero el valor más grande que se puede transmitir entre cliente y servidor se determina por el volumen de memoria disponible y el tamaño de los buffers de comunicaciones. Se puede cambiar el tamaño del buffer del mensaje, pero se tiene que hacer tanto en el lado de cliente como en el de servidor. Cabe señalar que cada valor BLOB o TEXT se representa internamente por un objeto alojado separadamente. Esto contrasta con el resto de tipos de columnas, para los que el almacenamiento tiene lugar una vez por columna al abrir la tabla. • MediumBlob y MediumText: un texto con un máximo de 16.777.215 caracteres. LongBlob y LongText: un texto con un máximo de caracteres 4.294.967.295. Hay que tener en cuenta que debido a los protocolos de comunicación los paquetes pueden tener un máximo de 16 Mb. Enum: campo que puede tener un único valor de una lista que se especifica. El tipo Enum acepta hasta 65535 valores distintos Set: un campo que puede contener ninguno, uno ó varios valores de una lista. La lista puede tener un máximo de 64 valores. Tipo de campo CHAR(n) VARCHAR(n) BLOB, TEXT MEDIUMBLOB, MEDIUMTEXT LONGBLOB, LONGTEXT ENUM('value1','value2',...) SET('value1','value2',...) Tamaño de Almacenamiento n bytes n +1 bytes Longitud +2 bytes Longitud +3 bytes Longitud +4 bytes 1 ó dos bytes dependiendo del número de valores 1, 2, 3, 4 ó 8 bytes, dependiendo del número de valores TINYBLOB, TINYTEXT Longitud+1 bytes Diferencia de almacenamiento entre los tipos Char y VarChar Valor '' 'ab' 'abcd' CHAR(4) '' 'ab ' 'abcd' Almace Almace VARCHAR(4) namiento namiento 4 bytes 4 bytes 4 bytes " 'ab' 'abcd' 1 byte 3 bytes 'abcdefgh' 'abcd' 4 bytes 'abcd' 5 bytes 4to ejemplo: Qué es la 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. Cada regla está basada en la que le antecede. La normalización se adoptó porque el viejo estilo de 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, vea la base de datos MiTienda. Si almacena todos los datos en la tabla Clientes, ésta podría verse como se muestra a continuación: Clientes ID_Cliente Apellidos Nombre_Producto1 Imagen_Producto1 Imagen_Producto2 Cantidad_Pedido Nombre_Cia_Envios Costo_Producto1 Nombre_Producto2 Fecha_Pedido Costo_Producto2 Nombre La tabla se ha descrito de manera abreviada pero aun así representa la idea general. ¿Cómo podría añadir un nuevo cliente en su tabla Clientes? Debería añadir un producto y un pedido también. ¿Qué tal si quisiera emitir un informe de todos los productos que vende? No podría separar fácilmente los productos de los clientes con una simple instrucción SQL. Lo bello de las bases de datos relacionales, si están bien diseñadas, es que puede hacer esto fácilmente. La nomlalización también hace las cosas fáciles de entender. Los seres humanos tenemos la tendencia de simplificar las cosas al máximo. Lo hacemos con casi todo desde los animales hasta con los automóviles. Vemos una imagen de gran tamaño y la hacemos menos compleja agrupando cosas similares juntas. Las guías que la nomlalización provee crean el marco de referencia para simplificar la estructura. En su base de datos de muestra es fácil detectar que usted tiene tres diferentes grupos: clientes, productos y pedidos. Si sigue las guías de la nomlalización, podría crear las tablas basándose en estos grupos. El proceso de nomlalización 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 mayoría de la gente le encantan las hojas de cálculo por la forma en la que manejan sus datos. El tiempo que le lleve reconfigurar su esquema para ajustarlo al proceso de nomlalización, siempre será bien Iinvertido. Al fin y al cabo, esto le tomará menos tiempo que el que tendría que invertir , para cortar y pegar sus columnas de datos para generar el infomle que quiere su jefe. Otra ventaja de la nomlalización 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 repetición de datos, lo que tiene como consecuencia un mucho menor uso de espacio en disco. Grados de normalización Existen básicamente tres niveles de normalización: 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 nomlalización. Por ejemplo, supongamos que su base de datos cumple con todas las reglas del segundo nivel de nomlalización. Se considera que está en la Segunda Fomla Normal. No siempre es una buena idea tener una base de datos conformada en el nivel más alto de normalización. Puede llevar aun nivel de complejidad que pudiera ser evitado si estuviera en un nivel más bajo de normalización. 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 fácil de seguir. Observe el esquema de la tabla Clientes de la base de datos. . Clientes ID Nombre Apellidos Nombre_Producto1 Costo_Producto1 Imagen_Producto1 Nombre_Producto2 Costo_Producto2 Cliente Imagen_Producto2 Fecha_Pedido Cantidad_Pedido Nombre -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. Cia Envios Eliminación de datos repetidos en una base de datos Clientes ID_Clientes Nombre Apellidos Direccion Numero_Pedido Fecha_Pedido Cantidad_Pedido Clave_Cia_Envios Nombre_Ci_ -- Pedidos Nombre_Productos Costo_Producto Imagen_Producto Envios Ahora tiene dos tablas. Pero todavía hay un problema. No hay forma de relacionar los datos de la tabla original con los de la nueva tabla. Para hacerlo, debe añadir un campo clave a la segunda tabla de forma que se establezca la relación. Añada a la tabla Productos una clave primaria que se llame ID_Producto y añada 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_Clientes Nombre Apellidos Direccion Numero_Pedido Fecha_Pedido Cantidad_Pedido Clave_Cia_Envios ID_Productos Nombre_Productos Costo_Producto Imagen_Producto -Así, se ha establecido una relación 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 cuántos otros clientes quieran comprarlos también. Además, el cliente necesitará haber pedido un producto para ser un cliente. Usted ya no está obligado a añadir un cliente cada vez que añade un nuevo producto a su inventario. Poner la base de datos en la Primera Forma Normal resuelve el problema de los encabezados de columna múltiples. Muy a menudo, los diseñadores de bases de datos inexpertos harán algo similar a la tabla no normalizada. Una y otra vez, crearán columnas que representen los mismos datos. En una empresa de servicios de electricidad, había una base de datos para el control de refacciones de una planta nuclear. La tabla de su base de datos, la cual contenía los números de parte de las refacciones, tenía una columna repetida más de treinta veces. Cada vez que una nueva parte se tenía que dar de alta, se creaba una nueva columna para almacenar la información. Obviamente, el diseño de la base de datos era bastante pobre y, por lo mismo, resultaba una pesadilla para sus programadores/administradores. La normalización ayuda a clarificar la base de datos ya organizarla en partes más pequeñas y más fáciles de entender. En lugar de tener que entender una tabla gigantesca y monolítica que tiene muchos diferentes aspectos, usted sólo tiene que entender objetos pequeños y más tangibles, así como las relaciones que guardan con otros objetos también pequeños. 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 término que describe a aquellos datos que no dependen de la clave de la tabla para identificarlos. En la base de datos de muestra, la información de pedidos está en cada uno de los registros. Sería mucho más simple utilizar únicamente el número del pedido. El resto de la información podría residir en su propia tabla. Una vez que haya organizado la información de pedidos. Eliminación Clientes ID_Productos ID_Clientes Nombre Apellidos Direccion Numero_Pedido Nombre_Cia_Envios de las dependencias Pedidos ID_Productos Nombre_Productos Cantidad_Pedido parciales -Segunda Productos ID_Producto Fecha_Compra Costos_Productos Imagen_Producto Forma Normal De nuevo, al organizar el esquema de esta forma puede reflejar el mundo real en su base de datos. Tendría que hacer algunos cambios en sus reglas del negocio para que esto fuera aplicable, pero para ilustrar la normalización, así está bien. Una de las mayores desventajas de la normalización es el tiempo que lleva hacerlo. La mayoría de la gente está demasiado ocupada, y emplear tiempo para asegurarse de que sus datos están normalizados cuando todo funciona más o menos bien, parece ser un desperdicio de tiempo. Pero no es así. Usted tendrá que emplear más tiempo arreglando una base de datos no normalizada que el que emplearía 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 añadir 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 normalización permite que los datos se acomoden de una manera natural dentro de los límites esperados. Una vez que ha alcanzado el nivel de la Segunda Forma Normal, se han controlado la mayoría de los problemas de lógica. Puede insertar un registro sin un exceso de datos en la mayoría de las tablas. Observando un poco más de cerca la tabla Clientes, vemos la columna Nombre_Cia_Envios. Ésta no es dependiente del cliente. El siguiente nivel de normalización explicará cómo solucionar esto. Tercera Forma Normal La regla de la Tercera Forma Normal señala 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. Podría separar estos datos de la tabla y ponerlos en una tabla aparte. Eliminación Clientes ID_cliente ID_Producto de los datos que no son claves para la Tercera Forma Normal Productos ID_Producto PedidoMaestro ID_Pedido PedidoDetallado ID_PedidoDetallado ID_Pedido Cias_Envios ID_Cia_Envios Nombre_Cia_Envios. Fecha_Pedido Nombre_Producto Fecha_Pedido Numero_Pedido ID_Cia_Envios Nombre Apellidos Direccion Costos_Productos Foto_Producto Cantidad_Pedidos Cantidad_Pedido Ahora todas sus tablas están en la Tercera Forma Normal. Esto le da más flexibilidad y previene errores de lógica 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 fácil de trabajar y expandir. Qué tan lejos debe llevar la normalización La siguiente decisión es ¿qué tan lejos debe llevar la normalización? La normalización es una ciencia subjetiva. Determinar las necesidades de simplificación depende de usted. Si su base de datos va a proveer información aun solo usuario para un propósito simple y existen pocas posibilidades de expansión, normalizar sus datos hasta la 3FN sea quizá algo extremoso. Las reglas de normalización existen como guías para crear tablas que sean fáciles de manejar, así como flexibles y eficientes. A veces puede ocurrir que normalizar sus datos hasta el nivel más alto no tenga sentido. Por ejemplo, suponga que añade una columna extra para la dirección en su base de datos. Es muy normal tener dos líneas para la dirección. El esquema de la tabla podría verse como se muestra a continuación: ID_Cliente Nombre Apellidos Direccion1 Direccion2 De acuerdo con las reglas, si aplica la Primera Forma Normal, la columna de dirección debería sacarse de esta tabla y reemplazarse con la clave de una nueva tabla. El resultado de este esquema se muestra a continuación: ID_Ciente Nombre Apellidos ID_Direccion ID_Cliente Direccion La base de datos ahora cumple con la Primera Forma Normal. Los clientes pueden tener más de una dirección. El problema aquí es que usted ha complicado demasiado una idea simple, por tratar de seguir las reglas de normalización. En el ejemplo mostrado, la segunda dirección es totalmente opcional. Está ahí sólo para colectar información que pudiera utilizarse como información de contacto. No hay necesidad de partir la tabla en dos y forzar las reglas de la normalización. En esta instancia, el exceso de normalización frustra el propósito para el que se utilizan los datos. Añade, de manera innecesaria, un nivel más de complejidad. Una buena forma de determinar si está llevando demasiado lejos su normalización, es ver el número de tablas que tiene. Un número grande de tablas pudiera indicar que está normalizando demasiado. Observe su esquema. ¿Está dividiendo tablas sólo para seguir las reglas o estas divisiones son en verdad prácticas? Éstas son el tipo de cosas que usted, el diseñador de la base de datos, necesita decidir. La experiencia y el sentido común lo pueden auxiliar para tomar la decisión correcta. La normalización no es una ciencia exacta. Es subjetiva. Existen seis niveles más de normalización que no se han discutido aquí. Ellos son Forma Normal Boyce-Codd, Cuarta Forma Normal (4NF), Quinta Forma Normal (5NF) o Forma Normal de Proyección-Unión, Forma Normal de Proyección-Unión Fuerte, Forma Normal de Proyección-Unión Extra Fuerte y Forma Normal de Clave de Dominio. Estas formas de normalización pueden llevar las cosas más allá de lo que necesita. Éstas existen para hacer una base de datos realmente relacional. Tienen que ver principalmente con dependencias múltiples y claves relacionales. En resumen La normalización es una técnica que se utiliza para crear relaciones lógicas apropiadas entre tablas de una base de datos. Ayuda a prevenir errores lógicos en la manipulación de datos. La normalización facilita también agregar nuevas columnas sin romper el esquema actual ni las relaciones. Existen varios niveles de normalización: Primera Forma Normal, Segunda Forma Normal, Tercera Forma Normal, Forma Normal Boyce-Codd, Cuarta Forma Normal, Quinta Forma Normal o Forma Normal de Proyección-Unión, Forma Normal de Proyección-Unión Fuerte, Forma Normal de Proyección-Unión Extra Fuerte y Forma Normal de Clave de Dominio. Cada nuevo nivel o forma lo acerca más a hacer su base de datos verdaderamente relacional. Se discutieron las primeras tres formas. Éstas proveen suficiente nivel de normalización para cumplir con las necesidades de la mayoría 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 común y práctico puede ayudarle a decidir cuándo normalizar.