Conceptos básicos del diseño de una base de datos

Importante:  Este artículo se ha traducido con traducción automática; vea la declinación de responsabilidades. Para su referencia, puede encontrar la versión en inglés de este artículo aquí.

Una base de datos correctamente diseñada le proporciona acceso a información actualizada y precisa. Dado que un diseño correcto es esencial para lograr los objetivos en trabajar con una base de datos, dedique tiempo necesaria para obtener información sobre los principios de un buen diseño tenga sentido. Al final, que es mucho más probable que acabe con una base de datos que satisfaga sus necesidades y fácilmente puede acomodar el cambio.

En este artículo se proporciona instrucciones para planear una base de datos de escritorio. Aprenderá cómo decidir qué información que necesita, cómo dividir la información en las tablas y columnas adecuadas y las tablas se relacionan entre sí. Debe leer este artículo antes de crear la primera base de datos de escritorio.

Importante: Access proporciona experiencias de diseño que permiten crear aplicaciones de base de datos para la Web. Muchas consideraciones de diseño son diferentes cuando diseñe para la Web. En este artículo no se trata el diseño de aplicaciones de base de datos Web. Para obtener más información, vea el artículo crear una base de datos para compartir en la Web.

En este artículo

Algunos términos de base de datos que debe conocer

¿Qué es el diseño de bases de datos?

El proceso de diseño

Determinar el propósito de la base de datos

Buscar y organizar la información necesaria

Dividir la información en tablas

Convertir los elementos de información en columnas

Especificar claves principales

Creación de relaciones de tabla

Ajustar el diseño

Aplicar las reglas de normalización


Algunas condiciones de base de datos necesita

Access organiza la información en tablas: listas de filas y columnas que recuerda a una hoja de cálculo o libros contables. En una base de datos simple, es posible que tenga una única tabla. La mayoría de las bases de datos necesita más de uno. Por ejemplo, es posible que tenga una tabla que almacena información sobre productos, otra tabla que almacena información acerca de los pedidos y otra tabla con información acerca de los clientes.

Imagen que muestra tres tablas en hojas de datos

Cada fila se denomina más correctamente un registroy cada columna, un campo. Un registro es una forma lógica y coherente de combinar información sobre algo. Es un campo de un solo elemento de la información: un tipo de elemento que aparece en cada registro. En la tabla productos, por ejemplo, cada fila o registro contiene la información acerca de un producto. Cada columna o el campo contiene algún tipo de información acerca de ese producto, como su nombre o el precio.

Volver al principio

¿Qué es una base de datos bien diseñada?

Determinados principios guían el proceso de diseño de base de datos. El primer principio es que información duplicada (también llamado datos redundantes) es incorrecta, porque residuos espacio y aumenta la probabilidad de errores e incoherencias. El segundo principio es que la exactitud y la integridad de la información importante. Si la base de datos contiene información incorrecta, los informes que extraen información de la base de datos también contener información incorrecta. Como resultado, las decisiones que se basen en dichos informes se luego estar mal informadas.

Un diseño de base de datos buena es, por lo tanto, uno que:

  • Divide la información en tablas basadas en temas para reducir los datos redundantes.

  • Proporciona acceso a la información necesaria para unir la información en las tablas según sea necesario.

  • Ayuda a garantizar la precisión y la integridad de su información.

  • Admite el procesamiento de datos e informes necesidades.

Volver al principio

El proceso de diseño

El proceso de diseño consta de los siguientes pasos:

  • Determinar el propósito de la base de datos   

    Esto le ayuda a prepararse para el resto de los pasos.

  • Buscar y organizar la información necesaria   

    Recopile todos los tipos de información que desea grabar en la base de datos, como el número de nombre y orden de producto.

  • Dividir la información en tablas   

    Dividir los elementos de información en entidades o temas, como productos o pedidos principales. Cada tema se convierte en una tabla.

  • Convertir los elementos de información en columnas   

    Decida qué información desea almacenar en cada tabla. Cada elemento se convierte en un campo y se muestra como una columna de la tabla. Por ejemplo, una tabla empleados puede incluir campos como apellido y fecha de contratación.

  • Especificar claves principales   

    Elija la clave principal de cada tabla. La clave principal es una columna que se utiliza para identificar inequívocamente cada fila. Un ejemplo podría ser el identificador de producto o Id.

  • Configurar las relaciones de tabla   

    Examine cada tabla y decida cómo los datos en una tabla relacionados con los datos en otras tablas. Agregar campos a las tablas o cree nuevas tablas para clarificar las relaciones según sea necesario.

  • Refinar el diseño   

    Analizar el diseño de errores. Crear las tablas y agregue algunos registros de datos de ejemplo. Vea si puede obtener los resultados que desee en las tablas. Realizar ajustes en el diseño, según sea necesario.

  • Aplicar las reglas de normalización   

    Aplicar las reglas de normalización de datos para ver si las tablas están estructuradas correctamente. Realizar ajustes en las tablas, según sea necesario.

Volver al principio

Determinar el propósito de la base de datos

Es una buena idea anote el propósito de la base de datos en papel: su finalidad, cómo piensa utilizarla y quién va a usar. Para una base de datos pequeña de un negocio particular, por ejemplo, puede escribir algo tan simple como "la base de datos de cliente mantiene una lista de información del cliente con el fin de generar envíos e informes". Si la base de datos es más compleja o utilizada por muchas personas, como ocurre normalmente en un entorno corporativo, la finalidad fácilmente podría ser uno o varios párrafos y debería incluir cuándo y cómo cada persona usará la base de datos. La idea es tener una declaración de objetivos bien desarrollado que se puede hacer referencia a lo largo del proceso de diseño. Tener como una instrucción le permite centrarse en los objetivos al tomar decisiones.

Volver al principio

Buscar y organizar la información necesaria

Para buscar y organizar la información necesaria, empiece con la información existente. Por ejemplo, podría registrar órdenes de compra en un cliente Contabilidad o mantener la información en los formularios de papel en un archivador. Recopilar esos documentos y enumerar cada tipo de información que se muestra (por ejemplo, cada cuadro que se rellena en un formulario). Si no tiene todos los formularios existentes, incluiría en el que se debe diseñar un formulario para registrar la información del cliente. ¿Qué información se ponga en el formulario? ¿Qué cuadros FILLIN crearía? Identificar y cada uno de estos elementos de lista. Por ejemplo, supongamos que actualmente mantener la lista de clientes en las tarjetas de índice. Estos elementos pueden mostrar que cada tarjeta contiene un nombre de los clientes, dirección, ciudad, estado, código postal y número de teléfono. Cada uno de estos elementos representa una columna posible en una tabla.

Cuando prepare esta lista, no se preocupe perfecta al principio. En su lugar, enumere cada elemento que llegue a la cuenta. Si alguien va a utilizar la base de datos, solicite sus ideas, demasiado. Puede ajustar la lista más adelante.

A continuación, considere los tipos de informes o la correspondencia que desea producir desde la base de datos. Por ejemplo, es recomendable un informe de ventas de productos para mostrar las ventas por región o un informe de resumen de inventario que muestra los niveles de inventario de productos. También puede generar cartas para enviar a los clientes que anuncia un evento de venta o una oferta. Diseño del informe en su cuenta y a continuación, imagine lo que tendrá un aspecto similar. ¿Qué información se debe colocar en el informe? Cada elemento de lista. Haga lo mismo para la carta modelo y para cualquier otro informe que prevé que va a crear.

Una persona imaginándose un informe de inventario de productos

Detenerse a pensar en los informes y el correo que desea crear le ayuda a identificar los elementos que necesita para la base de datos. Por ejemplo, suponga que ofrece a los clientes la oportunidad de cambiar de opinión a (o fuera de) actualizaciones periódicas por correo electrónico y desea imprimir una lista de las personas que han optado por. Para que la información de registro, agregar una columna "Enviar correo electrónico" a la tabla clientes. Para cada cliente, puede establecer el campo en Sí o no.

El requisito para enviar mensajes de correo electrónico a los clientes sugiere otro elemento. Una vez que sepa que un cliente desea recibir mensajes de correo electrónico, necesitará saber la dirección de correo electrónico en la que desea enviarles. Por lo tanto, debe registrar una dirección de correo electrónico de cada cliente.

Es conveniente para crear un prototipo de cada informe o listado de salida y considerar qué elementos necesita crear el informe. Por ejemplo, cuando examine una carta modelo, algunas cosas que vienen a la mente. Si desea incluir un saludo, por ejemplo, la cadena "D.", "Sra." o "Ms." que comienza un saludo, tendrá que crear un elemento de saludo. Además, normalmente puede comenzar una carta con "Estimado d. Pérez", en lugar de "estimado. Implicaría almacenar el". Esto sugiere que haría normalmente desea almacenar el apellido independiente del nombre.

Un punto clave que recordar es que debe dividir cada fragmento de información en sus partes más pequeñas. En el caso de un nombre para poder utilizar el apellido, dividirá el nombre en dos partes: nombre y apellido. Para ordenar un informe por apellido, por ejemplo, resulta útil para tener el nombre del cliente último almacenado por separado. En general, si desea ordenar, buscar, calcular o informe basado en un elemento de información, debe incluir ese elemento en su propio campo.

Piense en las preguntas que desea responder a la base de datos. ¿Por ejemplo, cuántas ventas de un determinado producto cierra mes pasado? ¿En vive sus mejores clientes? ¿Quién es el proveedor de los productos más vendidos? Anticipar estas preguntas le ayuda a cero en elementos adicionales para grabar.

Una vez recopilada esta información, ya está listo para el siguiente paso.

Volver al principio

Dividir la información en tablas

Para dividir la información en tablas, elija las entidades principales o los temas. Por ejemplo, después de buscar y organizar la información de una base de datos de ventas de productos, la lista preliminar podría ser similar a esta:

Elementos de información escritos a mano y agrupados en temas

Las entidades principales mostradas aquí son los productos, los proveedores, los clientes y los pedidos. Por lo tanto, tiene sentido empezar con estas cuatro tablas: uno para los datos sobre productos, otra para los datos sobre los proveedores, uno para los datos sobre los clientes y otra para datos sobre los pedidos. Aunque no se completa la lista, es un buen punto de partida. Puede seguir ajustando la lista hasta que tenga un diseño que funciona bien.

Cuando revise primero la lista preliminar de elementos, es posible que desee colocarlos en una sola tabla, en lugar de los cuatro que se muestra en la ilustración anterior. Aquí obtendrá información sobre por qué es una buena idea. Considere por un momento, la tabla se muestra aquí:

Imagen que muestra una tabla que contiene productos y proveedores

En este caso, cada fila contiene información sobre el producto y su proveedor. Como puede tener muchos productos del mismo proveedor, la información de nombre y la dirección del proveedor tiene que repetir muchas veces. Esto ocupa espacio de disco. Grabación de la información del proveedor solo una vez en una tabla proveedores independiente y, a continuación, Vincular tabla a la tabla productos, son una solución mucho mejor.

Otro problema de este diseño surge cuando necesita modificar información sobre el proveedor. Por ejemplo, suponga que necesita cambiar la dirección de un proveedor. Porque aparece en varios lugares, puede cambiar la dirección en un solo lugar accidentalmente pero olvida cambiar en las demás. Grabación de la información del proveedor en un único lugar, resuelve el problema.

Cuando diseñe su base de datos, intente grabar una sola vez de cada hecho siempre. Si siente que repetir la misma información en más de un lugar, como la dirección de un determinado proveedor, coloque esa información en una tabla independiente.

Por último, supongamos que solo un producto que le proporcionada Coho Winery y que desea eliminar el producto, pero mantener la información de nombre y la dirección del proveedor. ¿Cómo eliminaría el registro de producto sin perder la información del proveedor? No. Dado que cada registro contiene datos sobre un producto, así como datos sobre un proveedor, no puede eliminar unos sin eliminar la otra. Para mantener estos datos separados, debe dividir una tabla en dos: una tabla para obtener información de producto y otra tabla para obtener información de proveedor. Eliminar un registro de producto debería eliminar solo los datos sobre el producto, no los datos del proveedor.

Una vez que haya elegido al asunto representado por una tabla, columnas de esa tabla deben almacenar datos únicamente sobre el asunto. Por ejemplo, la tabla product debe almacenar datos sobre los productos. Dado que la dirección del proveedor es un dato del proveedor y no un hecho acerca del producto, pertenece en la tabla proveedor.

Volver al principio

Convertir los elementos de información en columnas

Para determinar las columnas de una tabla, decida qué información que necesita para realizar un seguimiento sobre el asunto se registra en la tabla. Por ejemplo, para la tabla Compradores, nombre, dirección, ciudad-provincia-código postal, enviar correo electrónico, saludo y correo electrónico conforman una buena lista de columnas iniciales. Cada registro de la tabla contiene el mismo conjunto de columnas, por lo que puede almacenar el nombre, dirección, ciudad-provincia-código postal, enviar un correo electrónico, saludo y correo electrónico información de dirección para cada registro. Por ejemplo, la columna de dirección contiene direcciones de los clientes. Cada registro contiene datos sobre un cliente y el campo dirección contiene la dirección de cliente.

Una vez haya determinado el conjunto inicial de columnas para cada tabla, puede refinar más las columnas. Por ejemplo, tiene sentido almacenar el nombre del cliente como dos columnas separadas: nombre y apellido, por lo que puede ordenar, buscar e indizar por esas columnas. Del mismo modo, la dirección consta en realidad de cinco componentes independientes, dirección, ciudad, estado, código postal y país o región, y también tiene sentido almacenarlos en columnas separadas. Por ejemplo, si desea realizar una búsqueda, la operación de filtrar u ordenar por estado, necesitará la información de estado almacenada en una columna distinta.

También debe tener en cuenta si la base de datos contiene información de origen nacional solo o internacional, también. Por ejemplo, si piensa almacenar direcciones internacionales, es mejor tener una columna región en lugar de estado, ya que esa columna puede incluir Estados nacionales y las regiones de otros países o regiones. Asimismo, código Postal tiene más sentido que código postal si va a almacenar direcciones internacionales.

La siguiente lista muestra algunas sugerencias para determinar las columnas.

  • No incluya datos calculados   

    En la mayoría de los casos, no se debe almacenar el resultado de los cálculos en tablas. En su lugar, puede tener acceso a realizar los cálculos cuando desee ver el resultado. Por ejemplo, supongamos que hay un informe de productos en el orden que se muestra el subtotal de unidades en orden para cada categoría de producto en la base de datos. Sin embargo, no hay ninguna columna subtotal unidades en orden de cualquier tabla. En su lugar, la tabla productos contiene una columna unidades en pedido que almacena las unidades en pedido de cada producto. Con esos datos, Access calcula el subtotal cada vez que se imprima el informe. El subtotal propiamente dicho no debe almacenarse en una tabla.

  • Almacenar la información en sus partes lógicas más pequeñas   

    Puede desear un único campo para nombres completos o nombres de productos junto con una descripción de producto. Si se combina más de un tipo de información en un campo, es difícil recuperar datos individuales más adelante. Intente dividir la información en partes lógicas. Por ejemplo, cree campos distintos para el nombre y apellido, o para descripción, categoría y nombre de producto.

Imagen que muestra elementos de información durante el proceso de diseño

Una vez ajustadas las columnas de datos de cada tabla, ya está listo para elegir la clave principal de cada tabla.

Volver al principio

Especificar claves principales

Cada tabla debe incluir una columna o un conjunto de columnas que identifica inequívocamente cada fila almacenada en la tabla. Suele ser un número de identificación exclusivo, como un número de ID de empleado o un número de serie. En la terminología de base de datos, esta información se denomina clave principal de la tabla. Access utiliza campos de clave principal para asociar rápidamente datos de varias tablas y reunir automáticamente los datos.

Si ya tiene un identificador único para una tabla, como un número de producto que identifica inequívocamente cada producto del catálogo, puede utilizar ese identificador como clave principal de la tabla, pero solo si los valores de esta columna siempre serán diferentes para cada registro. No puede tener valores duplicados en una clave principal. Por ejemplo, no use los nombres de las personas como clave principal, porque los nombres no son únicos. Es muy fácil que dos personas con el mismo nombre en la misma tabla.

Una clave principal siempre debe tener un valor. Si el valor de una columna puede quedar sin asignar o desconocido (un valor que faltan) en algún momento, no se pueden usar como un componente de una clave principal.

Siempre debe elegir una clave principal cuyo valor no cambiará. En una base de datos que usa más de una tabla, la clave principal de una tabla puede usarse como referencia en otras tablas. Si cambia la clave principal, el cambio debe aplicarse también a todos los que se hace referencia a la clave. Usar una clave principal que no cambie reduce la posibilidad de que se sincronizados con otras tablas que hacen referencia a él.

A menudo, un número único arbitrario sirve como clave principal. Por ejemplo, podría asignar a cada pedido un número de pedido únicos. Del número orden solo sirve para identificar el pedido. Una vez asignado, nunca cambia.

Si no tiene en cuenta una columna o un conjunto de columnas que podría ser una buena clave principal, considere la posibilidad de utilizar una columna que tiene el tipo de datos autonumeración. Cuando se utiliza el tipo de datos autonumeración, Access asigna automáticamente un valor para usted. Un identificador es este tipo; contiene información objetiva sobre la fila que representa. Identificadores de este tipo son perfectos para usarlos como clave principal porque no cambian. Una clave principal que contiene datos sobre una fila, un número de teléfono o un cliente nombre, por ejemplo, es más probable que cambie, ya que la propia información objetiva podría cambiar.

Imagen que muestra la tabla Productos con un campo de clave principal.

1. una columna establecida en el tipo de datos Autonumeración suele constituir una buena clave principal. No hay dos identificadores de producto son iguales.

En algunos casos, es aconsejable usar dos o más campos juntos, como la clave principal de una tabla. Por ejemplo, una tabla de detalles de pedido que almacena los elementos de línea para los pedidos usaría dos columnas en su clave principal: ID de pedido y el identificador de producto. Cuando una clave principal formada por más de una columna, también se denomina clave compuesta.

La base de datos de ventas de producto, puede crear una columna de autonumeración para cada una de las tablas que funcione como clave principal: IdProducto para la tabla productos, IdPedido para los pedidos de tabla, IdCliente para la tabla clientes e ID para la tabla proveedores.

Imagen que muestra elementos de información durante el proceso de diseño


Volver al principio

Creación de relaciones de tabla

Ahora que ha dividido la información en tablas, necesita una manera de volver a reunir la información de forma significativa. Por ejemplo, el siguiente formulario incluye información de varias tablas.

El formulario Pedidos

1. La información de este formulario procede de la tabla Clientes...

2... .la tabla empleados...

3... .la tabla de pedidos...

4... .la tabla de productos...

5... y la tabla de detalles de pedido.

Access es un sistema de administración de la base de datos relacional. En una base de datos relacional, se divide la información en tablas separadas, en función del tema. A continuación, use las relaciones de tablas para reunir la información según sea necesario.

Volver al principio

Crear una relación uno a varios

Considere este ejemplo: base de datos de pedidos de las tablas proveedores y productos en el producto. Un proveedor puede proporcionar un número de productos. Sigue que para cualquier proveedor representado en la tabla proveedores, puede haber muchos productos representados en la tabla de productos. Por lo tanto, la relación entre la tabla proveedores y la tabla productos es una relación uno a varios.

Concepto de uno a varios

Para representar una relación de uno a varios en el diseño de la base de datos, tome la clave principal del lado "uno" de la relación y agregarlo como una columna o columnas adicionales a la tabla del lado "varios" de la relación. En este caso, por ejemplo, agregar la columna ID de la tabla proveedores a la tabla de productos. Acceso a continuación, puede usar el número de identificación del proveedor de la tabla productos para localizar el proveedor correcto de cada producto.

La columna ID de la tabla productos se denomina clave externa. Una clave externa es la clave principal de otra tabla. La columna ID de la tabla productos es una clave externa porque también es la clave principal en la tabla proveedores.

Imagen que muestra elementos de información durante el proceso de diseño

Proporcionan la base para combinar tablas relacionadas estableciendo parejas de claves principales y externas. Si no está seguro de qué tablas deben compartir una columna común, identificar una relación uno a varios garantiza que las dos tablas implicadas, de hecho, requieren una columna compartida.

Volver al principio

Crear una relación varios a varios

Considere la relación entre la tabla productos y la tabla Orders.

Un solo pedido puede incluir más de un producto. Por otro lado, un solo producto puede aparecer en muchos pedidos. Por lo tanto, para cada registro en la tabla pedidos, puede haber varios registros en la tabla de productos. Y para cada registro de la tabla productos, puede haber varios registros en la tabla Orders. Este tipo de relación se denomina una relación varios a varios porque para cualquier producto, puede haber muchos pedidos; y en cualquier orden, puede ser muchos productos. Tenga en cuenta que para detectar relaciones varios a varios entre las tablas, es importante tener en cuenta ambos lados de la relación.

Los temas de las dos tablas, productos y pedidos: tienen una relación varios a varios. Esto supone un problema. Para comprender el problema, imagine lo que ocurre si ha intentado crear la relación entre las dos tablas agregando el campo identificador de producto a la tabla Orders. Para tener más de un producto por pedido, necesita más de un registro en la tabla Pedidos. Tendría que repetir la información del pedido para cada fila relacionada con un único pedido, lo que resulta en un diseño ineficaz que podría producir datos incorrectos. Ejecutar en el mismo problema si coloca el campo ID de la tabla productos: tendría varios registros en la tabla de productos para cada producto. ¿Cómo puede resolver este problema?

La respuesta es crear una tercera tabla, a menudo denominada tabla de unión, que divide la relación de varios a varios en dos relaciones uno a varios. Insertar la clave principal de cada una de las dos tablas en la tercera tabla. Como resultado, la tercera tabla registra cada aparición o instancia de la relación.

Una relación de varios a varios

Cada registro de la tabla de detalles de pedidos representa un artículo de línea en un pedido. Clave principal de la tabla de detalles de pedidos consta de dos campos: las claves externas de los tablas pedidos y productos. Usar el campo Id. de pedido por sí solo no funciona como clave principal para esta tabla, porque un pedido puede tener varios elementos de línea. El ID de pedido se repite para cada elemento de línea en un pedido, por lo que el campo no contiene valores únicos. Usar el campo identificador de producto únicamente no funciona, porque un solo producto puede aparecer en muchos pedidos diferentes. Pero juntas, los dos campos siempre generan un valor único para cada registro.

En la base de datos de ventas de producto, la tabla Pedidos y la tabla productos no están relacionados entre sí directamente. En su lugar, están relacionadas indirectamente a través de la tabla Order Details. La relación de varios a varios entre productos y pedidos se representa en la base de datos mediante dos relaciones uno a varios:

  • La tabla Pedidos y la tabla Detalles de pedidos tienen una relación uno a varios. Cada pedido puede tener más de un elemento de línea, pero cada elemento de la línea está conectado a un único pedido.

  • La tabla productos y la tabla Detalles de pedidos tienen una relación uno a varios. Cada producto puede tener varios artículos asociados, pero cada elemento de la línea que hace referencia a un solo producto.

En la tabla Detalles de pedido, puede determinar todos los productos en un orden determinado. También puede determinar todos los pedidos de un determinado producto.

Después de incorporar la tabla Detalles de pedido, la lista de tablas y campos sería algo parecido a esto:

Imagen que muestra elementos de información durante el proceso de diseño


Volver al principio

Crear una relación uno a uno

Otro tipo de relación es la relación de uno a uno. Por ejemplo, suponga que necesita registrar información complementaria sobre productos que apenas va a necesitar o que solo se aplica a unos pocos productos. Puesto que no necesita la información con frecuencia, y almacenar la información de la tabla productos crearía un espacio vacío para todos los productos que no se aplica, colocarla en una tabla independiente. Como la tabla productos, utiliza el identificador de producto como clave principal. La relación entre esta tabla complementaria y la tabla productos es una relación uno a uno. Para cada registro en la tabla Product, existe un único registro coincidente en la tabla complementaria. Cuando identifique esta relación, ambas tablas deben compartir un campo común.

Al detectar la necesidad de una relación uno a uno en la base de datos, tenga en cuenta si se puede incluir la información de las dos tablas juntos en una tabla. Si no desea hacerlo por algún motivo, tal vez porque daría como resultado una gran cantidad de espacio en blanco, la siguiente lista muestra cómo puede representar la relación en el diseño:

  • Si las dos tablas tienen el mismo tema, probablemente podrá definir la relación utilizando la misma clave principal en ambas tablas.

  • Si las dos tablas tienen temas diferentes con claves principales distintas, elija una de las tablas (cualquiera de ellas) e inserte su clave principal en la otra tabla como clave externa.

Determinar las relaciones entre tablas le ayuda a asegurarse de que tiene las tablas y columnas correctas. Cuando existe una relación uno a uno o uno a varios, las tablas implicadas deben compartir una o varias columnas comunes. Cuando existe una relación varios a varios, es necesaria una tercera tabla para representar la relación.

Volver al principio

Ajustar el diseño

Una vez que tenga las tablas, campos y las relaciones que necesita, debe crear y rellenar las tablas con datos de ejemplo y pruebe a trabajar con la información: creación de consultas, agregar nuevos registros y así sucesivamente. Esto le permitirá encontrar posibles problemas, por ejemplo, tendrá que agregar una columna que olvidó insertar durante la fase de diseño o es posible que tenga una tabla que debería dividir en dos tablas para eliminar datos duplicados.

Vea si puede usar la base de datos para obtener las respuestas que desee. Cree bocetos de los formularios e informes y compruebe si muestran los datos de que lo esperado. Buscar datos duplicados innecesarios y, si encuentra alguno, modifique el diseño para eliminarla.

Cuando pruebe la base de datos inicial, probablemente descubrirá mejorar. Estos son algunos aspectos que debe comprobar:

  • ¿Ha olvidado cualquiera de las columnas? Si es así, ¿pertenece la información de las tablas existentes? Si se trata de información sobre algo, necesitará crear otra tabla. Crear una columna para cada elemento de la información que necesita para realizar un seguimiento. Si no se puede calcular la información de otras columnas, es probable que necesite una nueva columna para el mismo.

  • ¿Son las columnas innecesarias porque se pueden calcular con los campos existentes? Si un elemento de información se puede calcular de otras columnas existentes, un descuento calculado del precio minorista, por ejemplo, normalmente es mejor hacerlo y evitar crear una nueva columna.

  • ¿Ha introducido información duplicada en alguna de las tablas? Si es así, es probable que necesite dividir la tabla en dos tablas que tienen una relación uno a varios.

  • ¿Tiene tablas con muchos campos, un número limitado de registros y muchos campos vacíos en registros individuales? Si es así, piense en volver a diseñar la tabla para que tenga menos campos y más registros.

  • ¿Se ha dividido cada elemento de información en sus partes más pequeñas? Si necesita informar, ordenar, buscar o calcular en un elemento de información, ponga ese elemento en su propia columna.

  • ¿Contiene cada columna datos sobre el asunto de la tabla? Si una columna no contiene información sobre el asunto de la tabla, pertenece en una tabla diferente.

  • ¿Son todas las relaciones entre tablas representados mediante campos comunes o mediante una tercera tabla? Relaciones uno a uno y de uno a varios requieren columnas comunes. Relaciones varios a varios requieren una tercera tabla.

Ajustar la tabla productos

Suponga que cada producto de la base de datos de ventas de producto se encuentra en la categoría general, como bebidas, condimentos o Marisco. La tabla productos podría incluir un campo que muestra la categoría de cada producto.

Supongamos que después de examinar y ajustar el diseño de la base de datos, decide almacenar una descripción de la categoría junto con su nombre. Si agregar un campo de descripción de la categoría a la tabla productos, tendrá que repetir la descripción de cada categoría para cada producto que se encuentra bajo la categoría, esto no es una buena solución.

Una solución mejor es convertir las categorías en un nuevo tema de la base de datos, con su propia tabla y su propia clave principal. A continuación, puede agregar la clave principal de la tabla de categorías a la tabla productos como clave externa.

Las tablas categorías y productos tienen una relación uno a varios: una categoría puede incluir más de un producto, pero un producto pertenece únicamente a una categoría.

Al revisar las estructuras de tabla, esté atento para grupos de repetición. Por ejemplo, considere la posibilidad de una tabla que contiene las columnas siguientes:

  • Id. de producto

  • Nombre

  • ID1 de producto

  • Nombre1

  • ID2 de producto

  • Nombre2

  • ID3 de producto

  • Nombre3

Aquí, cada producto es un grupo de repetición de las columnas es distinto de las demás solo agregando un número hasta el final del nombre de columna. Cuando vea columnas numeradas de esta forma, debe revisar el diseño.

Este tipo de diseño tiene varios defectos. Para empezar, obliga a colocar un límite superior en el número de productos. En cuanto supere ese límite, debe agregar un nuevo grupo de columnas a la estructura de tabla, que es una tarea administrativa importante.

Otro problema es que los proveedores que tengan menos que el número máximo de productos perderá espacio, ya que las columnas adicionales estará en blanco. El defecto más grave de este diseño es que dificulta muchas de las tareas a realizar, como ordenar o indizar la tabla por identificador de producto o nombre.

Siempre que aparezcan grupos extensibles, revise atentamente el diseño con vistas a dividir la tabla en dos. En el ejemplo anterior, es mejor usar dos tablas, una para proveedores y otra para productos, vinculadas por el identificador de proveedor.

Volver al principio

Aplicar las reglas de normalización

Puede aplicar las reglas de normalización de datos (a veces se denominan reglas de normalización) como el siguiente paso en el diseño. Use estas reglas para comprobar si las tablas están estructuradas correctamente. El proceso de aplicar las reglas para el diseño de la base de datos se denomina normalizar la base de datos, o simplemente, normalización.

Normalización es muy útil una vez representados todos los elementos de información y ha llegado a un diseño preliminar. La idea es asegurarse de que se han dividido los elementos de información en las tablas adecuadas. ¿Qué normalización no puede hacer es asegurarse de que tiene todos los elementos de datos correctos para empezar con.

Aplicar las reglas sucesivamente en cada paso para garantizar que su diseño llega a uno de lo que se conoce como "forma normal". Cinco formas normales ampliamente aceptadas: la primera forma normal a la quinta forma normal. En este artículo se abordan las tres primeras, porque todo lo necesario para la mayoría de los diseños de base de datos.

Primera forma normal

Primera forma normal establece que en cada intersección de fila y columna en la tabla, existe un único valor y nunca una lista de valores. Por ejemplo, no puede tener un campo denominado precio en las que colocar más de un precio. Si cree que cada intersección de filas y columnas como una celda, cada celda puede contener un único valor.

La segunda forma normal

Segunda forma normal exige que cada columna de clave no sea totalmente dependientes en toda la clave principal, no en la parte de la clave. Esta regla se aplica cuando tiene una clave principal consta de más de una columna. Por ejemplo, suponga que tiene una tabla que contiene las columnas siguientes, donde el identificador de producto e ID forman la clave principal:

  • Id. de pedido (clave principal)

  • Identificador de producto (clave principal)

  • Nombre del producto

Este diseño infringe la segunda forma normal, porque nombre de producto depende de identificador de producto, pero no en ID de orden, por lo que no depende de toda la clave principal. Debe quitar el nombre de producto de la tabla. Pertenece en una tabla diferente (productos).

Tercera forma normal

Tercera forma normal exige no sólo cada columna de clave no dependerá de toda la clave principal, sino que las columnas de clave no sean independientes entre sí.

Otra forma de diciendo esto es que cada columna de clave no deben depender de la clave principal y nada más que la clave principal. Por ejemplo, suponga que tiene una tabla que contiene las columnas siguientes:

  • IdProducto (clave principal)

  • Nombre

  • SRP

  • Descuento

Supongamos que descuento depende del precio de venta sugerido (SRP). Esta tabla infringe la tercera forma normal porque una columna de clave no, descuento, depende de otra columna de clave no, SRP. Independencia de la columna significa que debería poder cambiar cualquier columna de clave no sin afectar a cualquier otra columna. Si cambia un valor en el campo PVP, el descuento cambiar en consecuencia, así infringir esa regla. En este caso descuento se moverá a otra tabla cuya clave sea PVP.

Volver al principio

Nota: Declinación de responsabilidades de traducción automática: Este artículo se ha traducido con un sistema informático sin intervención humana. Microsoft ofrece estas traducciones automáticas para que los hablantes de otros idiomas distintos del inglés puedan disfrutar del contenido sobre los productos, los servicios y las tecnologías de Microsoft. Puesto que este artículo se ha traducido con traducción automática, es posible que contenga errores de vocabulario, sintaxis o gramática.

Compartir Facebook Facebook Twitter Twitter Enviar por correo electrónico Enviar por correo electrónico

¿Le ha sido útil esta información?

De acuerdo. ¿Algún comentario más?

¿Cómo podemos mejorarlo?

¡Gracias por sus comentarios!

×