3
16/5/2014 Fundamentos de la normalización de bases de datos http://support.microsoft.com/kb/283878/es 1/3 Support for Office 2003 has ended Microsoft ended support for Office 2003 on April 8, 2014. This change has affected your software updates and security options. Learn what this means for you and how to stay protected. Id. de artícu lo: 283878 - Ver los productos a los que se aplica este artículo Este artículo se publicó anteriormente con el número E283878 Principiante: se requieren conocimientos de la interfaz de usuario en equipos de usuario único. Para obtener una versión de este artículo para Microsoft Access 2000, vea 209534 (htt p://support.microsoft .com/kb/209534/ ) . Para obtener una versión de este artículo para Microsoft Access 95 o Microsoft Access 97, vea 100139 (htt p://support.microsoft .com/kb/1 00139/ ) . En este artículo se explica la terminología de normalización de bases de datos para principiantes. Tener un conocimiento básico de esta terminología resulta útil al tratar el diseño de una base de datos relacional. NOTA: Microsoft también ofrece una WebCast que explica los fundamentos de la normalización de bases de datos. Para ver esta WebCast, visite el siguiente sitio web de Microsoft: http://support.microsoft.com/servicedesks/webcasts/wc060600/wc060600.asp?fr=1  (http ://support.microsoft. com/serv icedesks/webcasts/w c060600/wc060600.asp? fr =1) Fundamentos de la normalización La normalización es el proceso de organizar los datos de una base de datos. Se incluye la creación de tablas y el establecimiento de relaciones entre ellas según reglas diseñadas tanto para proteger los datos como para hacer que la base de datos sea más flexible al eliminar la redundancia y las dependencias incoherentes. Los datos redundantes desperdician el espacio de disco y crean problemas de mantenimiento. Si hay que cambiar datos que existen en más de un lugar, se deben cambiar de la misma forma exactamente en todas sus ubicaciones. Un cambio en la 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 no en algún otro lugar de la base de datos. ¿Qué es una "dependencia incoherente"? Aunque es intuitivo para un usuario mirar en la tabla Clientes para buscar la dirección de un cliente en particular, puede no tener sentido mirar allí el salario del empleado que llama a ese cliente. El salario del empleado está relacionado con el empleado, o depende de él, y por lo tanto se debería pasar a la tabla Empleados. Las dependencias incoherentes pueden dificultar el acceso porque la ruta para encontrar los datos puede no estar o estar interrumpida. Hay algunas reglas en la normalización de una base de datos. Cada regla se denomina una "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, la base de datos se considera que está en la "tercera forma normal". Aunque son posibles otros niveles de normalización, la tercera forma normal se considera el máximo nivel necesario para la mayor parte de las aplicaciones. Al igual que con otras muchas reglas y especificaciones formales, en los escenarios reales no siempre se cumplen los estándares de forma perfecta. En general, la normalización requiere tablas adicionales y algunos clientes consideran éste un trabajo considerable. Si decide infringir una de las tres primeras reglas de la normalización, asegúrese de que su aplicación se anticipa a los problemas que puedan aparecer, como la existencia de datos redundantes y de dependencias incoherentes. En las descripciones siguientes se incluyen ejemplos. Primera forma normal Elimine los grupos repetidos de las tablas individuales. Cree una tabla independiente para cada conjunto de datos relacionados. Identifique cada conjunto de datos relacionados con una clave principal. No use varios campos en una sola tabla para almacenar datos similares. Por ejemplo, para realizar el seguimiento de un elemento del inventario que proviene de dos orígenes posibles, un registro del inv ent ario puede conten er campos para el Código de proveedor 1 y para el Código de proveedor 2. ¿Qué ocurre cuando se agrega un tercer proveedor? Agregar un campo no es la respuesta, requiere modificaciones en las tablas y el programa, y no admite fácilmente un número variable de proveedores. En su lugar, coloque toda la información de los proveedores en una tabla independiente denominada Proveedores y después vincule el inventario a los proveedores con el número de elemento como clave, o los proveedores al inventario con el código de proveedor como clave. Segunda forma normal Cree tabl as i nd e en di entes ara conun tos de valores ue se a li uen a varios re istros. Fundamentos de la normalización de bases de datos Resumen Más información

Normalización de Bases de Datos

Embed Size (px)

DESCRIPTION

Normalizacion de base de datos, SQL, fundamentosNormalizacion tipo 1Normalizacion tipo 2Normalizacion tipo 3

Citation preview

  • 16/5/2014 Fundamentos de la normalizacin de bases de datos

    http://support.microsoft.com/kb/283878/es 1/3

    Support for Office 2003 has ended

    Microsoft ended support for Office 2003 on April 8, 2014. This change has affected your software updates and security

    options.

    Learn what this means for you and how to stay protected.

    Id. de artculo: 283878 - Ver los productos a los que se aplica este artculo

    Este artculo se public anteriormente con el nmero E283878

    Principiante: se requieren conocimientos de la interfaz de usuario en equipos de usuario nico.

    Para obtener una versin de este artculo para Microsoft Access 2000, vea 209534 (http://support.microsoft.com/kb/209534/ ) .

    Para obtener una versin de este artculo para Microsoft Access 95 o Microsoft Access 97, vea 100139 (http://support.microsoft.com/kb/100139/ ) .

    En este artculo se explica la terminologa de normalizacin de bases de datos para principiantes. Tener un conocimiento bsico de esta terminologa resulta til

    al tratar el diseo de una base de datos relacional.

    NOTA: Microsoft tambin ofrece una WebCast que explica los fundamentos de la normalizacin de bases de datos. Para ver esta WebCast, visite el siguiente

    sitio web de Microsoft:

    http://support.microsoft.com/servicedesks/webcasts/wc060600/wc060600.asp?fr=1 (http://support.microsoft.com/servicedesks/webcasts/wc060600/wc060600.asp?fr=1)

    Fundamentos de la normalizacin

    La normalizacin es el proceso de organizar los datos de una base de datos. Se incluye la creacin de tablas y el establecimiento de relaciones entre ellas segn

    reglas diseadas tanto para proteger los datos como para hacer que la base de datos sea ms flexible al eliminar la redundancia y las dependencias

    incoherentes.

    Los datos redundantes desperdician el espacio de disco y crean problemas de mantenimiento. Si hay que cambiar datos que existen en ms de un lugar, se

    deben cambiar de la misma forma exactamente en todas sus ubicaciones. Un cambio en la direccin de un cliente es mucho ms fcil de implementar si los

    datos slo se almacenan en la tabla Clientes y no en algn otro lugar de la base de datos.

    Qu es una "dependencia incoherente"? Aunque es intuitivo para un usuario mirar en la tabla Clientes para buscar la direccin de un cliente en particular, puede

    no tener sentido mirar all el salario del empleado que llama a ese cliente. El salario del empleado est relacionado con el empleado, o depende de l, y por lo

    tanto se debera pasar a la tabla Empleados. Las dependencias incoherentes pueden dificultar el acceso porque la ruta para encontrar los datos puede no estar

    o estar interrumpida.

    Hay algunas reglas en la normalizacin de una base de datos. Cada regla se denomina una "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, la base de datos se considera que est en la "tercera forma normal". Aunque

    son posibles otros niveles de normalizacin, la tercera forma normal se considera el mximo nivel necesario para la mayor parte de las aplicaciones.

    Al igual que con otras muchas reglas y especificaciones formales, en los escenarios reales no siempre se cumplen los estndares de forma perfecta. En general,

    la normalizacin requiere tablas adicionales y algunos clientes consideran ste un trabajo considerable. Si decide infringir una de las tres primeras reglas de la

    normalizacin, asegrese de que su aplicacin se anticipa a los problemas que puedan aparecer, como la existencia de datos redundantes y de dependencias

    incoherentes.

    En las descripciones siguientes se incluyen ejemplos.

    Primera forma normal

    Elimine los grupos repetidos de las tablas individuales.

    Cree una tabla independiente para cada conjunto de datos relacionados.

    Identifique cada conjunto de datos relacionados con una clave principal.

    No use varios campos en una sola tabla para almacenar datos similares. Por ejemplo, para realizar el seguimiento de un elemento del inventario que proviene

    de dos orgenes posibles, un registro del inventario puede contener campos para el Cdigo de proveedor 1 y para el Cdigo de proveedor 2.

    Qu ocurre cuando se agrega un tercer proveedor? Agregar un campo no es la respuesta, requiere modificaciones en las tablas y el programa, y no admite

    fcilmente un nmero variable de proveedores. En su lugar, coloque toda la informacin de los proveedores en una tabla independiente denominada

    Proveedores y despus vincule el inventario a los proveedores con el nmero de elemento como clave, o los proveedores al inventario con el cdigo de

    proveedor como clave.

    Segunda forma normal

    Cree tablas independientes para conjuntos de valores que se apliquen a varios registros.

    Fundamentos de la normalizacin de bases dedatos

    Resumen

    Ms informacin

  • 16/5/2014 Fundamentos de la normalizacin de bases de datos

    http://support.microsoft.com/kb/283878/es 2/3

    Cree tablas independientes para conjuntos de valores que se apliquen a varios registros.

    Relacione estas tablas con una clave externa.

    Los registros no deben depender de nada que no sea una clave principal de una tabla, una clave compuesta si es necesario. Por ejemplo, considere la direccin

    de un cliente en un sistema de contabilidad. La direccin se necesita en la tabla Clientes, pero tambin en las tablas Pedidos, Envos, Facturas, Cuentas por

    cobrar y Colecciones. En lugar de almacenar la direccin de un cliente como una entrada independiente en cada una de estas tablas, almacnela en un lugar, ya

    sea en la tabla Clientes o en una tabla Direcciones independiente.

    Tercera forma normal

    Elimine los campos que no dependan de la clave.

    Los valores de un registro que no sean parte de la clave de ese registro no pertenecen a la tabla. En general, siempre que el contenido de un grupo de campos

    pueda aplicarse a ms de un nico registro de la tabla, considere colocar estos campos en una tabla independiente. Por ejemplo, en una tabla Contratacin de

    empleados, puede incluirse el nombre de la universidad y la direccin de un candidato. Pero necesita una lista completa de universidades para enviar mensajes

    de correo electrnico en grupo. Si la informacin de las universidades se almacena en la tabla Candidatos, no hay forma de enumerar las universidades que no

    tengan candidatos en ese momento. Cree una tabla Universidades independiente y vinclela a la tabla Candidatos con el cdigo de universidad como clave.

    EXCEPCIN: cumplir la tercera forma normal, aunque en teora es deseable, no siempre es prctico. Si tiene una tabla Clientes y desea eliminar todas las

    dependencias posibles entre los campos, debe crear tablas independientes para las ciudades, cdigos postales, representantes de venta, clases de clientes y

    cualquier otro factor que pueda estar duplicado en varios registros. En teora, la normalizacin merece el trabajo que supone. Sin embargo, muchas tablas

    pequeas pueden degradar el rendimiento o superar la capacidad de memoria o de archivos abiertos.

    Puede ser ms factible aplicar la tercera forma normal slo a los datos que cambian con frecuencia. Si quedan algunos campos dependientes, disee la

    aplicacin para que pida al usuario que compruebe todos los campos relacionados cuando cambie alguno.

    Otras formas de normalizacin

    La cuarta forma normal, tambin llamada Forma normal de Boyce Codd (BCNF, Boyce Codd Normal Form), y la quinta forma normal existen, pero rara vez se

    consideran en un diseo real. Si no se aplican estas reglas, el diseo de la base de datos puede ser menos perfecto, pero no debera afectar a la funcionalidad.

    Normalizar una tabla de ejemplo

    Estos pasos demuestran el proceso de normalizacin de una tabla de alumnos ficticia.

    1. Tabla sin normalizar:

    2. Primera forma normal: no hay grupos repetidos

    Las tablas slo deben tener dos dimensiones. Puesto que un alumno tiene varias clases, estas clases deben aparecer en una tabla independiente. Los

    campos Clase1, Clase2 y Clase3 de los registros anteriores son indicativos de un problema de diseo.

    Las hojas de clculo suelen usar la tercera dimensin, pero las tablas no deberan hacerlo. Otra forma de considerar ese problema es con una relacin de

    uno a varios y poner el lado de uno y el lado de varios en tablas distintas. En su lugar, cree otra tabla en la primera forma normal eliminando el grupo

    repetido (N clase), segn se muestra a continuacin:

    3. Segunda forma normal: eliminar los datos redundantes

    Observe los diversos valores de N clase para cada valor de N alumno en la tabla anterior. N clase no depende funcionalmente de N alumno (la clave

    principal), de modo que la relacin no cumple la segunda forma normal.

    Las dos tablas siguientes demuestran la segunda forma normal:

    Alumnos:

    Registro:

    N alumno Tutor Despacho-Tut Clase1 Clase2 Clase3

    1022 Garca 412 101-07 143-01 159-02

    4123 Daz 216 201-01 211-02 214-01

    N alumno Tutor Despacho-Tut N clase

    1022 Garca 412 101-07

    1022 Garca 412 143-01

    1022 Garca 412 159-02

    4123 Daz 216 201-01

    4123 Daz 216 211-02

    4123 Daz 216 214-01

    N alumno Tutor Despacho-Tut

    1022 Garca 412

    4123 Daz 216

    N alumno N clase

    1022 101-07

  • 16/5/2014 Fundamentos de la normalizacin de bases de datos

    http://support.microsoft.com/kb/283878/es 3/3

    4. Tercera forma normal: eliminar los datos no dependientes de la clave

    En el ltimo ejemplo, Despacho-Tut (el nmero de despacho del tutor) es funcionalmente dependiente del atributo Tutor. La solucin es pasar ese

    atributo de la tabla Alumnos a la tabla Personal, segn se muestra a continuacin:

    Alumnos:

    Personal:

    Id. de artculo: 283878 - ltima revisin: viernes, 12 de julio de 2013 - Versin: 6.4

    La informacin de este artculo se refiere a:

    Microsoft Office Access 2007Microsoft Office Access 2003Microsoft Access 2002 Standard Edition

    Palabras clave: kbinfo kbdesign kbdatabase kbhowto KB283878

    Propiedades

    1022 143-01

    1022 159-02

    4123 201-01

    4123 211-02

    4123 214-01

    N alumno Tutor

    1022 Garca

    4123 Daz

    Nombre Habitacin Dept

    Garca 412 42

    Daz 216 42