Descripción de Fundamentos de normalización de bases de datos en Access 2000

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

Para obtener una versión de Microsoft Access 97 de este artículo, consulte 100139.
Para obtener una versión de Microsoft Access 2002 de este artículo, consulte 283878.
Expandir todo | Contraer todo

En esta página

Resumen

En este artículo se explica la terminología de normalización de bases de datos para principiantes. 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
Para obtener información adicional acerca de este tema en una versión anterior de Access, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:
100139Fundamentos 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 que la base de datos sea más flexible eliminando 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 el acceso a los datos, ya que la ruta de acceso a los mismos puede estar rota o no encontrarse.

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.

En las siguientes descripciones puede ver algunos 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.

¿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 la pena. Sin embargo, la utilización de un gran número de tablas pequeñas puede perjudicar el rendimiento o superar la capacidad de memoria y de archivos abiertos del sistema.

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.

Normalizar una tabla de ejemplo

En los pasos siguientes se demuestra el proceso de normalización de una tabla de alumnos ficticia.
  1. Tabla sin normalizar:
    Contraer esta tablaAmpliar esta tabla
    Alumno #AsesorSala anticipadoClass1Class2Class3
    1022Jones41207-101143-01159-02
    4123Smith21601-20102-21101-214
  2. Primera forma normal: Sin grupos repetidos

    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 y Clase3 de los registros anteriores indican que existe un problema en el 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 ver el problema es considerar una relación de uno a varios; no se debe poner en la misma tabla el lado en el que hay un elemento y el lado en el que hay varios elementos. 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:
    Contraer esta tablaAmpliar esta tabla
    Alumno #AsesorSala anticipadoNº clase
    1022Jones41207-101
    1022Jones412143-01
    1022Jones412159-02
    4123Smith21601-201
    4123Smith21602-211
    4123Smith21601-214
  3. 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. Clase # no es funcionalmente dependiente de Nº alumno (clave principal), por lo que esta relación no es normal segundo formulario.

    Las dos tablas siguientes muestran la segunda forma normal:

    Alumnos

    Contraer esta tablaAmpliar esta tabla
    Alumno #AsesorSala anticipado
    1022Jones412
    4123Smith216

    Registro

    Contraer esta tablaAmpliar esta tabla
    Alumno #Nº clase
    102207-101
    1022143-01
    1022159-02
    412301-201
    412302-211
    412301-214
  4. Tercera forma normal: Eliminar datos no dependientes en la clave

    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:

    Alumnos

    Contraer esta tablaAmpliar esta tabla
    Alumno #Asesor
    1022Jones
    4123Smith

    Profesores

    Contraer esta tablaAmpliar esta tabla
    NombreSalónDepartamento
    Jones41242
    Smith21642

Referencias

Ahlo, M. Hamilton, Brown Randy y Peter Colclough. FoxPro 2: manual del programador A: experto orientación para la programación de Intensidad Industrial . John Wiley & Sons, octubre de 1991. 225-220 De páginas.

Jennings, Roger. utilizar Access 1.1 para Windows . Corporation, julio de 1993. 799 Páginas-800.

Propiedades

Id. de artículo: 209534 - Última revisión: viernes, 06 de agosto de 2004 - Versión: 2.2
La información de este artículo se refiere a:
  • Microsoft Access 2000 Standard Edition
Palabras clave: 
kbmt kbdatabase kbdesign kbinfo kbusage KB209534 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): 209534

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