Scribd Logo
Cargar

¡Te damos la bienvenida a Scribd!

  • 34 vistas

    Fundamentos de La Normalización de Bases de Datos PDF

    Cargado por

    joseph tobon

    Copyright:

    © All Rights Reserved
    Descargue como PDF, TXT o lea en línea desde Scribd

    Fundamentos de La Normalización de Bases de Datos PDF

    Cargado por

    joseph tobon
    34 vistas6 páginas

    Título original

    Fundamentos de la normalización de bases de datos.pdf

    Derechos de autor

    © © All Rights Reserved

    Formatos disponibles

    PDF, TXT o lea en línea desde Scribd

    ¿Le pareció útil este documento?

    ¿Este contenido es inapropiado?

    Copyright:

    © All Rights Reserved
    Descargue como PDF, TXT o lea en línea desde Scribd
    Descargar como pdf o txt
    34 vistas6 páginas

    Fundamentos de La Normalización de Bases de Datos PDF

    Cargado por

    joseph tobon

    Copyright:

    © All Rights Reserved
    Descargue como PDF, TXT o lea en línea desde Scribd
    Descargar como pdf o txt
    de 6

    Fundamentos de la normalización de bases

    de datos
    Se aplica: Microsoft Office Access 2007, Microsoft Office Access 2003

    Usuario inexperto: 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,
    consulte
    209534.
    Para obtener una versión de este artículo para Microsoft Access 95 o
    Microsoft Access 97, vea
    100139.

    Resumen

    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.
     

    Más información

    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 inventario puede contener
    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 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
    dirección de un cliente en un sistema de contabilidad. La dirección se necesita
    en la tabla Clientes, pero también en las tablas Pedidos, Envíos, Facturas,
    Cuentas por cobrar y Colecciones. En lugar de almacenar la dirección de un
    cliente como una entrada independiente en cada una de estas tablas,
    almacénela 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 más de un único registro de la tabla, considere
    colocar estos campos en una tabla independiente.

    Por ejemplo, en una tabla Contratación de empleados, puede incluirse el


    nombre de la universidad y la dirección de un candidato. Pero necesita una
    lista completa de universidades para enviar mensajes de correo electrónico en
    grupo. Si la información 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
    vincúlela a la tabla Candidatos con el código de universidad como clave.

    EXCEPCIÓN: cumplir la tercera forma normal, aunque en teoría es deseable,


    no siempre es práctico. Si tiene una tabla Clientes y desea eliminar todas las
    dependencias posibles entre los campos, debe crear tablas independientes
    para las ciudades, códigos postales, representantes de venta, clases de
    clientes y cualquier otro factor que pueda estar duplicado en varios registros.
    En teoría, la normalización merece el trabajo que supone. Sin embargo,
    muchas tablas pequeñas pueden degradar el rendimiento o superar la
    capacidad de memoria o de archivos abiertos.
    Puede ser más factible aplicar la tercera forma normal sólo a los datos que
    cambian con frecuencia. Si quedan algunos campos dependientes, diseñe la
    aplicación para que pida al usuario que compruebe todos los campos
    relacionados cuando cambie alguno.

    Otras formas de normalización

    La cuarta forma normal, también llamada Forma normal de Boyce Codd


    (BCNF, Boyce Codd Normal Form), y la quinta forma normal existen, pero rara
    vez se consideran en un diseño real. Si no se aplican estas reglas, el diseño de
    la base de datos puede ser menos perfecto, pero no debería afectar a la
    funcionalidad.

    Normalización de una tabla de ejemplo

    Estos pasos demuestran el proceso de normalización de una tabla de alumnos


    ficticia.
    1. Tabla sin normalizar:

    Despacho-
    Nº alumno Tutor Clase1 Clase2 Clase3
    Tut
    1022 García 412 101-07 143-01 159-02
    4123 Díaz 216 201-01 211-02 214-01

    2. Primera forma normal: no hay grupos repetidos

    Las tablas sólo 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 diseño.

    Las hojas de cálculo suelen usar la tercera dimensión, pero las tablas no
    deberían hacerlo. Otra forma de considerar ese problema es con una
    relación 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), según se muestra a
    continuación:

    Nº alumno Tutor Despacho-Tut Nº clase


    1022 García 412 101-07
    1022 García 412 143-01
    1022 García 412 159-02
    4123 Díaz 216 201-01
    4123 Díaz 216 211-02
    4123 Díaz 216 214-01

    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 relación no cumple la segunda forma
    normal.

    Las dos tablas siguientes demuestran la segunda forma normal:

    Alumnos:

    Nº alumno Tutor Despacho-Tut


    1022 García 412
    4123 Díaz 216

    Registro:

    Nº alumno Nº clase
    1022 101-07
    1022 143-01
    1022 159-02
    4123 201-01
    4123 211-02
    4123 214-01

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

    En el último ejemplo, Despacho-Tut (el número de despacho del tutor) es


    funcionalmente dependiente del atributo Tutor. La solución es pasar ese
    atributo de la tabla Alumnos a la tabla Personal, según se muestra a
    continuación:

    Alumnos:

    Nº alumno Tutor
    1022 García
    4123 Díaz
    Personal:

    Nombre Habitación Dept


    García 412 42
    Díaz 216 42

    Última actualización: 29/06/2017

    Novedades Store y Educación Empresa Desarrollad Compañía


    soporte or
    Xbox One X Office 365 para Microsoft Azure Trabajos
    Perfil de la cuenta escuelas Microsoft Visual
    Xbox One S Recursos para Studio Acerca de
    Centro de Microsoft Azure asociados de Microsoft
    Aplicaciones de descargas en educación Microsoft Red de
    Windows 10 desarrolladores Privacidad en
    Ventas y soporte Salud Microsoft
    Aplicaciones de TechNet
    Office Devoluciones y Inversionistas
    reembolsos Channel 9

    Seguimiento de Centro para


    pedidos desarrolladores
    de Office
    Soporte

     Español (México)

    Contacto Términos de uso Privacidad y cookies Marcas comerciales Seguridad y ecológico


    © Microsoft 2019

    También podría gustarte