ACC: Fundamentos de normalización de bases de datos

Seleccione idioma Seleccione idioma
Id. de artículo: 100139 - Ver los productos a los que se aplica este artículo
Principiante: Requiere conocimientos de la interfaz de usuario en equipos de usuario único.

Expandir todo | Contraer todo

En esta página

Resumen

Este artículo explica los fundamentos de la terminología de normalización de bases de datos. Es fundamental comprender las bases de esta terminología para describir el diseño de una bases de datos relacional.

Nota : Microsoft también ofrece una WebCast que explica los fundamentos de normalización de bases de datos. Si desea ver esta presentación en línea en inglés, visite el siguiente sitio Web de Microsoft:
http://support.microsoft.com/servicedesks/webcasts/wc060600/wc060600.asp?fr=1
Nota : para ver esta información para Microsoft Access 2000, por favor, consulte el siguiente artículo en la Microsoft Knowledge Base:
209534ACC2000: Fundamentos de normalización de bases de datos

Más información

Descripción de la normalización

La normalización es el proceso de organizar los datos en una base de datos. Esto incluye crear tablas y establecer relaciones entre las tablas según reglas diseñadas tanto para proteger los datos y para hacer más flexible la base de datos eliminando dos factores: redundancia y dependencias incoherentes.

Los datos redundantes desperdician espacio en disco y crean problemas de mantenimiento. Si es necesario cambiar datos que aparecen en más de un sitio, el cambio deberá ser exactamente igual en todos estos sitios. Por ejemplo, un cambio de dirección de un cliente es mucho más fácil de implementar si los datos sólo se almacenan en la tabla Clientes y en ningún otro lugar de la base de datos.

¿Qué es una "dependencia incoherente"? Aunque para un usuario puede resultar intuitivo buscar la dirección de un determinado cliente en la tabla Clientes, es posible que no tenga sentido buscar en esa misma tabla el sueldo del empleado que atiende a dicho cliente. El salario del empleado está relacionado con el empleado (es decir, existe una dependencia entre ambos), por lo que debe moverse a la tabla Empleados. Las dependencias incoherentes pueden dificultar a acceso; puede ser la ruta de acceso encontrar los datos falta o está dañado.

Existen unas cuantas reglas para la normalización de bases de datos. Cada regla se denomina "forma normal" Si se cumple la primera regla, se dice que la base de datos está en la "primera forma normal" Si se cumplen las tres primeras reglas, se considera que la base de datos está en la "tercera forma normal" Aunque existen otros niveles de normalización, se considera que la tercera forma normal es el máximo nivel necesario para la mayoría de las aplicaciones.

Como sucede con muchas reglas formales y especificaciones, los escenarios del mundo real no siempre permiten cumplir a la perfección estas reglas. En general, la normalización requiere tablas adicionales y algunos clientes encontrar este complejo. Si decide no cumplir alguna de las tres primeras reglas de normalización, asegúrese de que su aplicación anticipe cualquier posible problema, como datos redundantes y dependencias incoherentes.

Nota : las descripciones siguientes incluyen ejemplos.

Primera forma normal

  • Eliminar grupos repetidos en tablas individuales.
  • Crear una tabla diferente para cada conjunto de datos relacionados.
  • Identificar cada conjunto de datos relacionados mediante una clave principal.
No utilizar varios campos en una única tabla para almacenar datos similares. Por ejemplo, para realizar el seguimiento de un artículo de inventario que puede provenir de dos orígenes, un registro del inventario puede contener campos para el Código de proveedor 1 y el Código de proveedor 2.

¿Pero qué sucede al agregar un tercer proveedor? La solución no es agregar un campo; hace falta modificar el programa y la tabla, y no se adapta fácilmente a cambios dinámicos en el número de proveedores. En su lugar, coloque toda información de proveedor en una tabla independiente denominada proveedores, inventario de vínculo a los proveedores con una clave de número de artículos o proveedores al inventario con una clave de código de proveedor.

Segunda forma normal

  • Crear tablas independientes para conjuntos de valores que se apliquen a varios registros.
  • Relacionar dichas tablas mediante una clave externa.
Los registros tan sólo deben depender de la clave principal de una tabla (si es necesario, puede ser una clave compuesta). Por ejemplo, piense en la dirección de un cliente en un sistema de contabilidad. La dirección es necesaria por la tabla Customers, sino también por las tablas pedidos, envíos, facturas, clientes y colecciones. En lugar de almacenar la dirección del cliente como una entrada diferente en cada tabla, almacénela en un único lugar, ya sea en la tabla Clientes o en una tabla de direcciones independiente.

Tercera forma normal

  • Eliminar los campos que no dependan de la clave.
Los valores de un registro que no forman parte de la clave de dicho registro no pertenecen a esa tabla. En general, siempre que el contenido de un grupo de campos se puede aplicar a más de un registro de la tabla, debe tener en cuenta la posibilidad de incluir dichos campos en una tabla independiente.

Por ejemplo, en una tabla de Selección de empleados pueden incluirse el nombre y la dirección de la universidad de un candidato. Sin embargo, necesita una lista completa de todas las universidades para realizar envíos de correo. Si la información acerca de la universidad se encuentra en la tabla Candidatos, no hay ninguna forma de ver las universidades que no tengan candidatos. Cree una tabla Universidades separada y vincúlela a la tabla Candidatos con una clave de código de universidad.

excepción : cumplir la tercera forma normal, aunque teóricamente es deseable, no siempre es práctico. Si tiene una tabla Clientes y desea eliminar todas las posibles dependencias entre campos, debe crear tablas independientes para ciudades, códigos postales, representantes de ventas, clases de clientes y cualquier otro factor que pueda aparecer duplicado en varios registros. En teoría, la normalización merece dedicarse; sin embargo, muchas tablas pequeñas pueden degradar el rendimiento o superar los archivos abiertos y las capacidades de memoria.

Una posibilidad es aplicar la tercera forma normal únicamente a los datos que cambien con frecuencia. Si aún quedan campos dependientes, diseñe la aplicación de forma que solicite al usuario que compruebe todos los campos relacionados cuando se produzca un cambio en cualquiera de ellos.

Otras formas de normalización

Existe una cuarta forma normal, llamada también Forma normal de Boyce Codd (BCNF), y una quinta forma normal, pero pocas veces se consideran prácticas en un diseño. La omisión de estas reglas puede dar como resultado una tabla que no sea perfecta, pero no debería afectar a su funcionamiento.
               **********************************
                 Examples of Normalized Tables
               **********************************

 Normalization Examples:

 Unnormalized table:

    Student#   Advisor   Adv-Room  Class1   Class2   Class3
    -------------------------------------------------------
    1022       Jones      412      101-07   143-01   159-02
    4123       Smith      216      201-01   211-02   214-01
				
  1. Primera forma normal: NO REPEATING GROUPS

    Tablas deben tener sólo dos dimensiones. Como cada alumno está inscrito en varias clases, éstas deben aparecer en una tabla independiente. Los campos Clase1, clase2, & Class3 en el registro anterior son indicaciones de problemas de diseño.

    En las hojas de cálculo se utiliza con frecuencia la tercera dimensión, pero no debe hacerse en las tablas. Otra forma de observar este problema: con una relación uno a varios, no coloque el uno lado y el lado varios en la misma tabla. En su lugar, cree otra tabla en la primera forma normal eliminando el grupo de repetición (Nº clase), como se muestra a continuación:
           Student#   Advisor   Adv-Room    Class#
           ---------------------------------------
           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
    					
  2. Segunda forma normal: Eliminar datos REDUNDANTES

    Tenga en cuenta los varios valores de Nº clase para cada valor de Nº alumno en la tabla anterior. Nº clase no es funcionalmente dependiente de Nº alumno (clave principal), por lo que esta relación no es la segunda forma normal.

    Las dos tablas siguientes muestran la segunda forma normal:
        Students:   Student#    Advisor   Adv-Room
                    ------------------------------
                    1022        Jones       412
                    4123        Smith       216
    
        Registration:   Student#    Class#
                        ------------------
                        1022        101-07
                        1022        143-01
                        1022        159-02
                        4123        201-01
                        4123        211-02
                        4123        214-01
    					
  3. Tercera forma normal: Eliminar los datos no dependientes ON KEY

    En el último ejemplo anticipado-sala (número de oficina del Asesor) depende funcionalmente en el atributo de Asesor. La solución es mover dicho atributo de la tabla alumnos a la tabla personal, como se muestra a continuación:
        Students:   Student#    Advisor
                    -------------------
                    1022        Jones
                    4123        Smith
    
        Faculty:    Name    Room    Dept
                    --------------------
                    Jones   412     42
                    Smith   216     42
    					

Referencias

Para obtener información adicional acerca de cómo diseñar una base de datos, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:
234208ACC2000: "Descripción Relational Database Design" documentos disponibles en el Centro de descarga
"Guía del programador de FoxPro 2 A", Hamilton M. Ahlo SR. et al., páginas 220-225, libros de M & T, 1991

"Utilizar Access para Windows, Roger Jennings, páginas 799-800, Corporation, 1993

Propiedades

Id. de artículo: 100139 - Última revisión: jueves, 18 de enero de 2007 - Versión: 2.1
La información de este artículo se refiere a:
  • Microsoft Access 1.0 Standard Edition
  • Microsoft Access 1.1 Standard Edition
  • Microsoft Access 2.0 Standard Edition
  • Microsoft Access 95 Standard Edition
  • Microsoft Access 97 Standard Edition
Palabras clave: 
kbmt kbinfo kbusage KB100139 KbMtes
Traducción automática
IMPORTANTE: Este artículo ha sido traducido por un software de traducción automática de Microsoft (http://support.microsoft.com/gp/mtdetails) en lugar de un traductor humano. Microsoft le ofrece artículos traducidos por un traductor humano y artículos traducidos automáticamente para que tenga acceso en su propio idioma a todos los artículos de nuestra base de conocimientos (Knowledge Base). Sin embargo, los artículos traducidos automáticamente pueden contener errores en el vocabulario, la sintaxis o la gramática, como los que un extranjero podría cometer al hablar el idioma. Microsoft no se hace responsable de cualquier imprecisión, error o daño ocasionado por una mala traducción del contenido o como consecuencia de su utilización por nuestros clientes. Microsoft suele actualizar el software de traducción frecuentemente.
Haga clic aquí para ver el artículo original (en inglés): 100139
Renuncia a responsabilidad de los contenidos de la KB sobre productos a los que ya no se ofrece asistencia alguna
El presente artículo se escribió para productos para los que Microsoft ya no ofrece soporte técnico. Por tanto, el presente artículo se ofrece "tal cual" y no será actualizado.

Enviar comentarios

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com