Normalización de bases de datos

Normalización de bases de datos es el proceso de organización de la campos y tablas de un base de datos relacional para reducir al mínimo redundancia. Normalización consiste en dividir las tablas grandes en mesas más pequeñas (y menos redundantes) y definir las relaciones entre ellos. El objetivo es aislar datos para que adiciones, supresiones y modificaciones de un campo pueden ser hechas en una tabla y luego se propagó por el resto de la base de datos usando las relaciones definidas.

Edgar F. Codd, el inventor de la Modelo relacional, introdujo el concepto de normalización y de lo que hoy conocemos como la primera forma Normal (1NF) en 1970. Codd pasó a definir la segunda forma Normal (2NF) y tercera Normal ()3NF) en 1971, y Codd y Boyce define la forma Normal de Boyce-Codd (BCNF) en 1974. Informalmente, una tabla de base de datos relacional es a menudo descrita como "normalizado" si está en la tercera forma Normal. La mayoría de las tablas 3NF están libres de anomalías de inserción, actualización y eliminación.

Una pieza estándar de dirección de diseño de base de datos es que el diseñador debe crear primero un diseño totalmente normalizado; Entonces selectiva Denormalización se puede realizar para rendimiento razones.

Un ejemplo típico de la normalización que es un ID único en todas partes se almacena en el sistema, pero su nombre se lleva a cabo en sólo una tabla. El nombre puede actualizarse más fácilmente en una fila de una tabla. Una actualización en un ejemplo típica sería la compañía RIM cambiando su nombre a BlackBerry. Esa actualización se realizaría en un solo lugar e inmediatamente se mostrará el nombre correcto de "BlackBerry" en todo el sistema.

Objetivos

Un objetivo básico de la primera forma normal definido por Codd en 1970 era permitir datos para poder consultar y manipulados usando un "lenguaje secundario de datos universal" anclados en lógica de primer orden. (SQL es un ejemplo de un datos sub idioma, aunque uno que Codd considerado tan seriamente defectuosa.)

Los objetivos de normalización más allá de 1NF (primera forma Normal) fueron indicados como sigue por Codd:

1. para liberar a la colección de las relaciones de dependencias indeseables de inserción, actualización y eliminación;

2. para reducir la necesidad de reestructuración de la colección de relaciones, se introducen nuevos tipos de datos, y así aumentan la vida útil de los programas de aplicaciones;

3. para hacer el modelo relacional más informativos para los usuarios;

4. para hacer la colección de relaciones neutral a las estadísticas de consulta, donde estas estadísticas están obligadas a cambiar a medida que pasa el tiempo.

— E.F. Codd, "La mayor normalización del modelo relacional Base de datos"

Las secciones a continuación dan detalles de cada uno de estos objetivos.

Libre de la base de datos de las anomalías de modificación

Un anomalía de actualización. Empleado 519 se muestra como tener direcciones diferentes en diferentes registros.

Un anomalía de inserción. Hasta que el nuevo miembro de la Facultad, el Dr. Newsome, es asignado para al menos un curso, no se registrarán sus datos.

A anomalía de eliminación. Toda la información sobre el Dr. Giddens se pierde si cesa temporalmente a ser asignado a los cursos.

Cuando se realiza un intento de modificar (actualizar, insertar o eliminar de) una tabla, no deseados efectos secundarios pueden seguir. No todas las tablas pueden sufrir de estos efectos secundarios; por el contrario, los efectos secundarios pueden surgir sólo en tablas que no han sido suficientemente normalizadas. Una tabla normalizada podría tener uno o más de las siguientes características:

• La misma información puede expresarse en varias filas; por lo tanto las actualizaciones a la mesa pueden causar inconsistencias lógicas. Por ejemplo, cada registro de una tabla "Empleados" habilidades"podría contener un ID de empleado, empleado de dirección y habilidad; por lo tanto un cambio de la dirección de un empleado en particular potencialmente tendrá que aplicarse a múltiples registros (uno por cada habilidad). Si la actualización no se realiza a través de éxito — si, es decir, la dirección del empleado se actualiza en algunos registros, pero no a otros — a continuación, la tabla queda en un estado incoherente. Específicamente, la tabla proporciona respuestas contradictorias a la pregunta de cuál es la dirección de este empleado en particular. Este fenómeno es conocido como un anomalía de actualización.
• Hay circunstancias en las que ciertos hechos no podrán grabarse en absoluto. Por ejemplo, cada registro en una tabla "Facultad y sus cursos" podría contener una facultad ID, nombre de la Facultad, Facultad de contratar a fecha y curso código — así podemos grabar los detalles de cualquier miembro de la facultad que enseña al menos un curso, pero nosotros no podemos registrar los detalles de un miembro de la facultad recién contratados que aún no ha sido asignado para enseñar los cursos excepto estableciendo el código del curso en null. Este fenómeno es conocido como un anomalía de inserción.
• Bajo ciertas circunstancias, cancelación de los datos que representan ciertos hechos exige eliminación de datos que representa hechos totalmente diferentes. La tabla "Facultad y sus cursos" descrita en el ejemplo anterior sufre este tipo de anomalía, por si un miembro del cuerpo docente cesa temporalmente a ser asignado a los cursos, debemos eliminar el último de los registros en los que aparece ese miembro de la Facultad, efectivamente eliminar también el miembro de la Facultad, a menos que ponemos el código curso a null en el propio registro. Este fenómeno es conocido como un anomalía de eliminación.

Minimizar el rediseño al extender la estructura de base de datos

Cuando una estructura de base de datos totalmente normalizada se amplía para dar cabida a nuevos tipos de datos, los aspectos de la estructura de base de datos existentes pueden permanecer inalterados en gran parte o totalmente. Como resultado, interactuando con la base de datos de aplicaciones son mínimamente afectadas.

Tablas normalizadas y la relación entre una tabla normalizada y otro, espejo reales conceptos y sus interrelaciones.

Evitar el sesgo hacia un patrón particular de consultas

Tablas normalizadas son convenientes para las consultas generales. Esto significa que cualquier consulta contra estas tablas, incluyendo futuras consultas cuyos detalles no pueden ser previstos, es compatibles. En contraste, las tablas que no se normalizan prestan a algunos tipos de consultas, pero no en otros.

Por ejemplo, considere a una librería en línea cuyos clientes mantengan listas de los libros que les gustaría tener. Para la consulta obvia, esperada — qué libros quiere este cliente? — es suficiente para almacenar lista de deseos del cliente en la tabla como, digamos, una cadena homogénea de autores y títulos.

Con este diseño, sin embargo, la base de datos puede contestar solamente una sola consulta. No puede por sí mismo responder interesante pero consultas imprevistas: ¿Cuál es el libro más deseado para? ¿Qué clientes están interesados en espionaje WWII? ¿Cómo comparan Lord Byron sus poetas contemporáneos? Las respuestas a estas preguntas deben provenir de herramientas adaptables especiales completamente separadas de la base de datos. Una herramienta puede ser software escrito especialmente para manejar estas consultas. Este software adaptable especial tiene un solo propósito: en efecto para normalizar el campo no normalizada.

Pueden contestar consultas imprevistas trivial y enteramente dentro del marco de la base de datos, con una tabla normalizada.

Ejemplo

Consultar y manipular los datos dentro de una estructura de datos que no se normaliza, tales como la siguiente representación de non-1NF de transacciones de tarjetas de crédito de los clientes, implica más complejidad que es realmente necesario:

Atención al cliente	Transacciones
Jones	ID TR Fecha Cantidad 12890 14 de octubre de 2003 −87 12904 15 de octubre de 2003 −50
Wilkinson	ID TR Fecha Cantidad 12898 14 de octubre de 2003 −21
Stevens	ID TR Fecha Cantidad 12907 15 de octubre de 2003 −18 14920 20 de noviembre de 2003 −70 15003 27 de noviembre de 2003 −60

Corresponde a cada cliente un Grupo de repetición de las transacciones. La evaluación automatizada de cualquier consulta relativa a las transacciones de los clientes por lo tanto ampliamente implica dos etapas:

1. Desembalar los grupos uno o más clientes de transacciones que permite las transacciones individuales en un grupo para ser examinado, y
2. Derivando un resultado de consulta basado en los resultados de la primera etapa

Por ejemplo, con el fin de averiguar la suma monetaria de todas las transacciones que ocurrieron en octubre de 2003 para todos los clientes, el sistema tendría que saber que lo primero debe descomprimir el Transacciones Grupo de cada cliente, y luego suma el Cantidades de todas las transacciones donde obtenidas así el Fecha de las cataratas de transacción en octubre de 2003.

Uno de los importantes ideas de Codd era que esta complejidad estructural siempre se pudo quitar completamente, llevando mucho mayor poder y flexibilidad en las consultas de forma podría ser formulado (por usuarios y aplicaciones) y evaluados (por el DBMS). Normalizado el equivalente de la estructura anterior se vería así:

Atención al cliente	Cust. ID
Jones	1
Wilkins	2
Stevens	3

Cust. ID	ID TR	Fecha	Cantidad
1	12890	14 de octubre de 2003	−87
1	12904	15 de octubre de 2003	−50
2	12898	14 de octubre de 2003	−21
3	12907	15 de octubre de 2003	−18
3	14920	20 de noviembre de 2003	−70
3	15003	27 de noviembre de 2003	−60

Ahora cada fila representa una transacción de tarjeta de crédito individual, y el DBMS puede obtener la respuesta de interés, simplemente por encontrar todas las filas con una fecha cae en octubre y sumar sus cantidades. La estructura de datos pone todos los valores en igualdad de condiciones, exponiendo cada uno el DBMS directamente, así que cada uno potencialmente puede participar directamente en las consultas; mientras que en la situación anterior algunos valores fueron encajados en las estructuras de nivel inferior que debían tratarse especialmente. En consecuencia, el diseño normalizado se presta al proceso de consulta para fines generales, mientras que el diseño de unnormalized no. La versión normalizada también permite al usuario cambiar el nombre del cliente en un lugar y protectores contra errores que surgen si está mal escrito el nombre del cliente en algunos registros.

Antecedentes de normalización: definiciones

Dependencia funcional

En una tabla determinada, un atributo Y se dice que tiene un dependencia funcional en un conjunto de atributos X (escrito X → Y) si y sólo si cada X valor se asocia precisamente uno Y valor. Por ejemplo, en una tabla "Empleados" que incluye los atributos "ID de empleado" y "Empleado fecha de nacimiento", la dependencia funcional {ID de empleado} → {fecha de nacimiento de empleado} se rendirían. De las dos oraciones anteriores que cada {ID de empleado} se asocia con precisamente uno {fecha de nacimiento de empleado} se deduce.

Dependencia funcional completo

Un atributo es completamente funcionalmente dependiente de un conjunto de atributos X si es:

• funcionalmente dependiente de X, y
• No funcionalmente dependiente en cualquier subconjunto adecuado de x. {Dirección empleado} es una dependencia funcional en {ID de empleado, habilidad}, pero no un completo dependencia funcional, porque es también dependiente de {ID de empleado}. Incluso por el retiro de {habilidad} dependencia funcional sigue siendo entre {dirección empleado} y {ID de empleado}.

Dependencia transitiva

A dependencia transitiva es una dependencia funcional indirecta, en el que X→ Z Sólo en virtud de X→ Y y Y→ Z.

Dependencia funcional trivial

Una dependencia funcional trivial es una dependencia funcional de un atributo en un superconjunto de sí mismo. {ID de empleado, dirección empleado} → {Dirección empleado} es trivial, como {dirección empleado} → {Dirección empleado}.

Dependencia multivalor

A dependencia multivalor es una restricción según la cual la presencia de determinadas filas de una tabla implica la presencia de ciertas otras filas.

Unirse a la dependencia

Una mesa T está sujeto a un Únete a dependencia If T siempre puede ser recreado por unir varias tablas cada uno con un subconjunto de los atributos de T.

Superkey

A Superkey es una combinación de atributos que pueden utilizarse para identificar un registro de base de datos. Una tabla puede tener muchas superkeys.

Clave de candidato

A clave de candidato es un subgrupo especial de superkeys que no tienen ninguna información superflua en ellos: es un superkey mínimo.

Ejemplo: Una tabla con los campos < nombre >, < edad >, < SSN > y < extensión telefónica > tiene muchos superkeys posibles. Tres de estos son < SSN >, < teléfono supletorio, nombre > y < SSN, nombre >. De esos, sólo < SSN > es una llave candidato como los otros contienen información no necesaria para identificar registros ('SSN' aquí se refiere al número de Seguro Social, que es único para cada persona).

Atributo non-prime

Una primera es un atributo que no se produce en cualquier clave de candidato. Dirección empleado sería un atributo de primera en la tabla "Empleados" habilidades".

Atributo principal

Una privilegiada, por el contrario, es un atributo que se producen en una llave candidato.

Clave principal

Una llave de candidato en una relación puede ser designada la clave principal. Mientras que puede ser una práctica común (o incluso una necesaria en algunos ambientes), es estrictamente notacional y no tiene relación con la normalización. Con respecto a la normalización, candidato todas las llaves tienen derecho igual y son tratados igual.

Formas normales

El formas normales (Abrev. NF) de la teoría de la base de datos relacional de proporcionar criterios para determinar el grado de una tabla de inmunidad contra inconsistencias lógicas y anomalías. Cuanto mayor sea la forma normal aplicable a una mesa, el menos vulnerable es. Cada tabla tiene un "forma normal superior" (HNF): por definición, una mesa siempre cumple con los requisitos de la HNF y de todas formas normales inferiores a su HNF; por definición, una mesa tampoco cumplen los requisitos de cualquier forma normal superior su HNF.

Las formas normales son aplicables a las tablas individuales; decir que es una base de datos en forma normal n es decir, que todas sus tablas están en forma normal n.

Los recién llegados al diseño de base de datos a veces Supón que normalización procede de manera iterativa, es decir, un diseño de 1NF primero se normaliza a 2NF, luego a 3NF y así sucesivamente. Esto no es una descripción exacta de cómo funciona la normalización típicamente. Una mesa sensatamente diseñada es probable que sea en 3NF al primer intento; Además, si es 3NF, es abrumadoramente probable tener un HNF de 5NF. Lograr las "mayores" formas normales (sobretodo 3NF) no generalmente requiere un gasto adicional de esfuerzo por parte de la diseñadora, porque las tablas 3NF generalmente no necesitan ninguna modificación para cumplir los requisitos de estas formas normales superiores.

A continuación se resumen las principales formas normales.

	Forma normal	Definido por	In	Breve definición
1NF	Primera forma normal	Dos versiones: E.F. Codd (1970), C.J. fecha (2003)	1970 y 2003	El dominio de cada uno atributo contiene sólo atómico los valores y el valor de cada atributo contiene sólo un único valor de dicho dominio.
2NF	Segunda forma normal	E.F. Codd	1971	Ningún atributo de primera en la tabla es funcionalmente dependientes en un subconjunto adecuado de cualquier clave de candidato
3NF	Tercera forma normal	Dos versiones: E.F. Codd (1971), C. Zaniolo (1982)	1971 y 1982	Cada atributo de primera es no transitivamente dependiente de cada clave candidata en la tabla. Se eliminan los atributos que no contribuyen a la descripción de la clave primaria de la tabla. En otras palabras, no está permitido ninguna dependencia transitiva.
EKNF	Forma Normal de clave primaria	C. Zaniolo	1982	Cada dependencia funcional no triviales en la tabla es la dependencia de un atributo clave primaria o dependencia de un superkey
BCNF	Forma normal de Boyce-Codd	Boyce y E.F. Codd	1974	Cada dependencia funcional no triviales en la tabla es una dependencia en una Superkey
4NF	Cuarta forma normal	Ronald Fagin	1977	Cada no trivial dependencia multivalor en la tabla es una dependencia de un superkey
5NF	Quinta forma normal	Ronald Fagin	1979	Cada no trivial Únete a dependencia en la tabla está implícito por los superkeys de la tabla
DKNF	Forma normal dominio/clave	Ronald Fagin	1981	Cada restricción sobre la mesa es un consecuencia lógica de las limitaciones de dominio y restricciones de clave de la tabla
6NF	Sexta forma normal	C.J. fecha, Hugh Darwen, y Nikos Lorentzos	2002	Tabla no características dependencias unirse no trivial en absoluto (con referencia a operador de unir generalizada)

Denormalización

Artículo principal: Denormalización

Bases de datos destinados a procesamiento de transacciones en línea (OLTP) son típicamente más normalizados que destinados a bases de datos procesamiento analítico en línea (OLAP). Aplicaciones OLTP se caracterizan por un alto volumen de transacciones pequeñas tales como actualizar un récord de ventas en una caja de supermercado. La expectativa es que cada transacción Irán a la base de datos en un estado coherente. Por el contrario, las bases de datos destinados a operaciones de OLAP son principalmente "leer más" bases de datos. Aplicaciones OLAP tienden a extraer los datos históricos que se ha acumulado durante un largo período de tiempo. Estas bases de datos, pueden facilitar datos redundantes o "denormalized" inteligencia de negocios aplicaciones. En concreto, tablas dimensionales en un esquema en estrella a menudo contienen datos denormalized. Los datos redundantes o denormalized deben ser controlados cuidadosamente durante extraer, transformar, carga Procesamiento (ETL) y los usuarios no deben permitirse a ver los datos hasta que se encuentra en un estado consistente. La alternativa normalizada para el esquema en estrella es la esquema de copo de nieve. En muchos casos, la necesidad de desnormalización ha disminuido como computadoras y software RDBMS se han vuelto más poderosos, pero desde datos volúmenes generalmente han aumentado junto con hardware y rendimiento de software, bases de datos OLAP a menudo todavía utilizan esquemas denormalized.

Denormalización también se utiliza para mejorar el rendimiento en los equipos más pequeños como en registradoras computarizadas y dispositivos móviles, ya que éstos pueden usar los datos para consulta sólo (por ejemplo, las búsquedas de precio). Denormalización también puede usarse cuando no RDBMS existe para una plataforma (como Palm), o no los cambios deben ser realizados en los datos y una rápida respuesta es crucial.

Non-primera forma normal (NF² o N1NF)

Desnormalización es lo contrario de la normalización. En reconocimiento de que denormalización puede ser deliberada y útil, la forma normal de primer no es una definición de los diseños de bases de datos que no se ajustan a la primera forma normal, permitiendo "conjuntos y los conjuntos que dominios atributo" (Tschiang 1982). Los lenguajes utilizados para consultar y manipular datos en el modelo deben extenderse por consiguiente para apoyar tales valores.

Una manera de ver esto es considerar tales valores estructurados como tipos especializados de valores (dominios), con sus propios lenguajes específicos de dominio. Sin embargo, lo que generalmente significa no-1NF modelos es el enfoque en el que el modelo relacional y los lenguajes utilizados para consultarlo se amplió con un mecanismo general para dicha estructura; por ejemplo, la Modelo relacional anidado apoya el uso de las relaciones como valores de dominio, mediante la adición de dos operadores adicionales (nido y UNNEST) para el Álgebra relacional que puede crear y aplanar las relaciones anidadas, respectivamente.

Considere la siguiente tabla:

Primera forma Normal

Persona	Color favorito
Bob	azul
Bob	rojo
Jane	verde
Jane	amarillo
Jane	rojo

Asumir que una persona tiene varios colores favoritos. Obviamente, colores favoritos consisten en un conjunto de colores modelado por la tabla dada. Para transformar un 1NF en una tabla de NF² que un operador «nido» es necesaria que extiende el Álgebra relacional de las formas normales superiores. Aplicar el operador "nido" a la mesa de 1NF produce en la siguiente tabla NF²:

No-primera forma Normal

Persona	Colores favoritos
Bob	Color favorito azul rojo
Jane	Color favorito verde amarillo rojo

Para transformar esta tabla NF² a un 1NF que un operador "unnest" es necesaria que extiende el Álgebra relacional de las formas normales superiores. El unnest, en este caso, sería "colores" en su propia tabla.

Aunque "unnest" es el inverso matemático al "nido", el operador «nido» no es siempre el inverso matemático de "unnest". Otra restricción necesaria es para que los operadores que biyectiva, que es cubierto por el Forma Normal de particiones (PNF).

Forma categórica Normal

Un esquema relacional tales que cada tabla 1) unarios o 2) una función binaria entre tablas unario es un Presentación de un Categoría libre generado. Una instancia en un esquema de tal es (una presentación de) una funtor en la categoría libre para el Categoría de conjuntos. Si el esquema más impone limitaciones de equivalencia de camino, entonces el esquema denota un finitamente presentados categoría (que intuitivamente es el cociente de la categoría libre subyacente de las limitaciones de la equivalencia de camino). Un esquema que denota una categoría finitamente presentada se dice que es en forma categórica normal (véase Migración de datos functorial).

Véase también

• Aspecto (programación)
• Regla de negocio
• Forma canónica
• Preocupación transversal
• Base de datos de prueba
• Optimización (informática)
• Refactorización
• Asunción de relación universal

Notas y referencias

• Ponencia: "no primer Normal forman relaciones" por G. Jaeschke, H. -J Tschiang; Centro científico de IBM Heidelberg. -> Papel estudiando normalización y Denormalización operadores nidifican y unnest suavemente descrito al final de esta página de la wiki.

Lectura adicional

• Consejos de litt: normalización
• Fecha, J. C. (1999), Una introducción a los sistemas de base de datos (8ª ed.). Addison-Wesley Longman. ISBN 0-321-19784-4.
• Kent, w. (1983) Guía Simple para cinco formas normales en teoría de base de datos relacional, Communications of the ACM, vol. 26, págs. 120-125
• H.-J. Tschiang, p. Pistor estructuras de datos para un integrado de datos Base de sistema de gestión y recuperación de información

Enlaces externos

• Conceptos básicos de normalización de bases de datos por Mike Chapple (About.com)
• Intro de normalización de bases de datos, Parte 2
• Una introducción a la normalización de bases de datos por Mike Hillyer.
• Un tutorial sobre las 3 primeras formas normales por Fred Coulson
• Ejemplos de normalización DB
• Descripción de los fundamentos de la normalización de bases de datos por Microsoft
• Normalización de bases de datos y técnicas de diseño por Barry Wise, recomienda la lectura para el MIS de Harvard.
• Guía Simple para cinco formas normales en teoría de base de datos relacional

Otras Páginas

• Huella de ADN
• Causas del dolor por cancer
• Necesidades de desarrollo estrategia de reuniones
• Lista de caracteres de la ley y el orden (seccion Ejecutiva Asistente de fiscales de distrito)
• Sandberg, California (comunidades no incorporadas de la categoria en el Condado de Los Angeles, California)
• IOS (redireccion desde OS X iPhone)
• Albaro
• TachoSil
• Games for Windows Live
• Comprobacion de la presencia
• Fierrabras (opera)
• Linea del oeste del carril
• Samsung Galaxy Mega
• SFHAM
• Nokia N9
• Ideas clave en el pensamiento humano