Conceptos Básicos Acces

3/5/2021 Conceptos básicos del diseño de una base de datos - Access
Conceptos básicos del diseño de una

base de datos
Access para Microsoft 365 Access 2019 Access 2016 Access 2013 Access 2010
Una base de datos correctamente diseñada le permite obtener acceso a información actualizada y
precisa. Como es esencial tener un diseño correcto para lograr sus objetivos de trabajar con una base
de datos, tiene sentido invertir el tiempo necesario para obtener información sobre los principios de
un buen diseño. Al final, es mucho más probable que acabe con una base de datos que se ajusta a sus
necesidades y que puede adaptarse fácilmente al cambio.
En este artículo se proporcionan instrucciones para planear una base de datos de escritorio. Aprenderá
a decidir qué información necesita, cómo dividir esa información en las tablas y columnas adecuadas,
y cómo se relacionan entre sí esas tablas. Lea este artículo antes de crear su primera base de datos de
escritorio.
Importante: Access proporciona experiencias de diseño que le permiten crear aplicaciones de bases de

datos para la Web. Hay muchas consideraciones de diseño que son diferentes cuando diseña para la
Web. En este artículo no se explica el diseño de aplicaciones de bases de datos web. Para más
información, vea el artículo Crear una base de datos de Access para compartirla en la Web.
En este artículo
Algunos términos de base de datos que debe conocer
¿Qué es una base de datos bien diseñada?
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

https://support.microsoft.com/es-es/office/conceptos-básicos-del-diseño-de-una-base-de-datos-eb2159cf-1e30-401a-8084-bd4f9c9ca1f5 1/21
Especificar las claves principales
Crear las relaciones de tablas
Refinar el diseño
Aplicar las reglas de normalización
Algunos términos de base de datos que debe conocer

Access organiza la información en tablas: listas de filas y columnas que recuerdan a una hoja de
cálculo o a los libros de contabilidad. En una base de datos simple, es posible que solo tenga una
tabla. Para la mayoría de las bases de datos necesitará tener más de una. Por ejemplo, puede que
tenga una tabla que almacena información sobre productos, otra que almacena información sobre
pedidos y otra tabla con información sobre clientes.
Cada fila se denomina, más correctamente, un registro y cada columna, un campo. Un registro es una
forma clara y coherente de combinar información sobre algo. Un campo es un único elemento de
información, un tipo de elemento que aparece en cada registro. En la tabla de productos, por ejemplo,
cada fila o registro contiene la información de un producto. Cada columna o campo contiene algún
tipo de información sobre el producto, como su nombre o el precio.
Principio de página
¿Qué es una base de datos bien diseñada?

Algunos principios guían el proceso de diseño de la base de datos. El primer principio es que la
información duplicada (también denominada datos redundantes) es perjudicial, porque se pierde
espacio y aumenta la probabilidad de errores e incoherencias. El segundo principio es que la
corrección y la integridad de información es importante. Si la base de datos contiene información
incorrecta, los informes que extraigan la información de la base de datos también contendrán
información incorrecta. Como resultado, las decisiones que tome basándose en dichos informes
estarán mal informadas.
Un buen diseño de base de datos es, por tanto, aquel que:
Divide la información en tablas basadas en temas para reducir los datos redundantes.
Proporciona a Access la información necesaria para unir la información en las tablas según sea
necesario.
Ayuda a respaldar y garantizar la precisión y la integridad de la información.
Se ajusta a sus necesidades de informes y procesamiento de datos.
El proceso de diseño
El proceso de diseño consta de los siguientes pasos:
Esto le ayudará a prepararse para los pasos restantes.
Recopile todos los tipos de información que podría querer registrar en la base de datos, como los
nombres de producto y los números de pedido.
Divida los elementos de información en entidades principales o temas, como Productos o Clientes.
Después, cada tema se convierte en una tabla.
Decida qué información quiere almacenar en cada tabla. Cada elemento se convierte en un campo y
se muestra como una columna en la tabla. Por ejemplo, una tabla de empleados podría incluir
campos como Apellidos y Fecha de contratación.
Elija la clave principal de cada tabla. La clave principal es una columna que se usa para identificar
cada fila. Un ejemplo podría ser Id. de producto o Id. de pedido.
Establecer las relaciones de tablas
Busque en cada tabla y decida cómo se relacionan los datos en una tabla con los datos de otras
tablas. Agregue campos a las tablas o cree tablas para aclarar las relaciones, según sea necesario.
Perfeccionar el diseño
Analice el diseño en busca de errores. Cree las tablas y agregue unos cuantos registros de datos de
ejemplo. Compruebe si puede obtener los resultados que quiere de las tablas. Haga algunos ajustes
en el diseño, si es necesario.
Aplique las reglas de normalización de datos para ver si las tablas están estructuradas
correctamente. Haga algunos ajustes en las tablas, si es necesario.

Es una buena idea anotar el propósito de la base de datos en un papel: su propósito, cómo espera
usarla y quién la usará. Por ejemplo, para una base de datos pequeña para un negocio familiar, escriba
algo como: "La base de datos de clientes es una lista con información de los clientes cuya finalidad es
el envío de correo y la creación de informes". Si la base de datos es más compleja o la usan muchas
personas, como ocurre normalmente en un entorno corporativo, el propósito podría constar
fácilmente de 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 desarrollada a la que se pueda hacer
referencia en todo el proceso de diseño. Tener ese resumen le ayuda a centrarse en sus objetivos
cuando tome decisiones.

Para buscar y organizar la información necesaria, empiece con la información existente. Por ejemplo,
podría registrar los pedidos de compra en un libro de contabilidad o guardar la información de los
clientes en formularios de papel en un archivo. Recopile dichos documentos y enumere cada tipo de
información que se muestra (por ejemplo, cada cuadro que rellene en un formulario). Si no tiene
ningún formulario existente, imagine en su lugar que tiene que diseñar un formulario para registrar la
información del cliente. ¿Qué información incluiría en el formulario? ¿Qué cuadros de relleno crearía?
Identifique y enumere cada uno de estos elementos. Por ejemplo, suponga que actualmente guarda la
lista de clientes en las tarjetas de índice. Al examinar dichas tarjetas podría revelar que cada una
contiene un nombre de cliente, dirección, ciudad, estado, código postal y número de teléfono. Cada
uno de estos elementos representa una posible columna en una tabla.
Mientras prepare esta lista, no se preocupe de hacerla perfecta desde el principio. En su lugar,
enumere todos los elementos que se le ocurran. Si la base de datos la usará alguien más, pregúntele
también sobre sus ideas. Podrá perfeccionar la lista más adelante.
Después, tenga en cuenta los tipos de informes o correspondencia que podría querer crear a partir de
la base de datos. Por ejemplo, puede que quiera un informe de ventas de un producto para mostrar
las ventas por región o un informe de resumen de inventario que muestre los niveles de inventario del
producto. También es posible que quiera generar cartas modelo para enviar a los clientes que
anuncien un evento de venta u ofrezcan una mejora. Diseñe el informe en su mente y luego imagine
su aspecto. ¿Qué información incluiría en el informe? Enumere todos los elementos. Haga lo mismo
para la carta modelo y para cualquier otro informe que tenga previsto crear.
Pararse a pensar en los informes y correspondencia que podría querer crear le ayudará a identificar los
elementos que necesitará en la base de datos. Por ejemplo, suponga que los clientes tienen la
posibilidad de darse de alta (o de baja) de las novedades enviadas periódicamente por correo
electrónico, y que quiere imprimir una lista de los usuarios que se han dado de alta. Para registrar esa
información, agrega una columna "Enviar correo electrónico" a la tabla de clientes. Para cada cliente,
puede establecer el campo en Sí o No.
El requisito de enviar mensajes de correo a los clientes sugiere otro elemento del registro. Una vez
que sepa que un cliente quiere recibir mensajes de correo, también deberá saber la dirección de
correo electrónico a la que enviárselos. Por tanto, necesita registrar una dirección de correo
electrónico para cada cliente.
Tiene sentido crear un prototipo de cada informe o listado de salida, y considerar qué elementos
deberá generar el informe. Por ejemplo, cuando examina una carta modelo, podrían venirle a la mente
algunas consideraciones. Si quiere incluir un saludo formal, por ejemplo, la cadena "Sr.", "Sra." o "Srta."
con la que comienza un saludo, tendrá que crear un elemento de saludo. Además, tal vez quiera
comenzar una carta con "Estimado Sr. Alcalá" en lugar de "Estimado. Sr. Jorge Alcalá". Esto sugiere que
normalmente querría almacenar el apellido separado del nombre.
Un punto clave que recordar es que debería dividir cada fragmento de información en partes más
pequeñas. En el caso de un nombre, para poder usar el apellido, dividirá el nombre en dos partes:
nombre y apellido. Para ordenar un informe por apellidos, por ejemplo, resulta útil tener el apellido
del cliente almacenado por separado. En general, si quiere ordenar, buscar, calcular o crear informes
en función de un elemento de información, debe crear un campo propio para ese elemento.
Piense en las preguntas que tal vez quiere que responda la base de datos. Por ejemplo, ¿cuántas
ventas de un producto destacado se cerraron el mes pasado? ¿Dónde viven sus mejores clientes?
¿Quién es el proveedor de su producto más vendido? Anticipar estas preguntas le ayuda a centrarse
en qué elementos adicionales registrar.
Una vez recopilada esta información, está listo para pasar al siguiente paso.

Para dividir la información en tablas, elija las entidades principales, o asuntos. Por ejemplo, después de
encontrar y organizar la información para una base de datos de ventas de un producto, la lista
preliminar podría ser similar a la siguiente:
Las principales entidades que se muestran aquí son los productos, los proveedores, los clientes y los
pedidos. Por tanto, tiene sentido comenzar con estas cuatro tablas: una para los datos sobre
productos, otra para datos sobre proveedores, otra para los datos sobre clientes y otra para los datos
sobre pedidos. Aunque la lista no está completa con ellas, es un buen punto de partida. Puede seguir
ajustando la lista hasta que tenga un diseño que funcione bien.
Cuando revise por primera vez la lista preliminar de elementos, es posible que esté tentado a incluirlos
en una sola tabla, en lugar de las cuatro que se muestran en la ilustración anterior. A continuación
obtendrá información sobre por qué es una mala idea. Considere por un momento la tabla que se
muestra aquí:
En este caso, cada fila contiene información sobre el producto y su proveedor. Dado que un mismo
proveedor puede suministrarle una gran cantidad de productos, el nombre y la dirección de ese
proveedor tendrán que repetirse muchas veces. Esto supone un desperdicio de espacio en disco.
Registrar la información del proveedor una sola vez en una tabla independiente para los proveedores
y vincular esa tabla a la de productos es una solución mucho mejor.
Un segundo problema con este diseño surge cuando es necesario modificar la información sobre el
proveedor. Por ejemplo, supongamos que necesita cambiar la dirección de un proveedor. Al aparecer
en varios lugares, accidentalmente podría cambiar la dirección en un solo lugar y olvidarse de
cambiarla también en los demás. Si registra la información del proveedor en un único lugar, se evitará
el problema.
Al diseñar la base de datos, intente siempre registrar cada hecho una sola vez. Si se encuentra
repitiendo la misma información en más de un lugar, como la dirección de un determinado proveedor,
coloque dicha información en una tabla aparte.
Por último, supongamos que Coho Winery suministra un solo producto y que quiere eliminar el
producto pero conservar la información de nombre y dirección del proveedor. ¿Cómo se elimina el
registro del producto sin perder la información de proveedor? No se puede. Dado que cada registro
contiene datos sobre un producto y datos sobre un proveedor, no puede eliminar uno sin eliminar el
otro. Para mantener estos datos separados, debe dividir la tabla en dos: una tabla para la información
de productos y otra para la información de proveedores. Al eliminar un registro de producto, solo
eliminaría los datos del producto, no los datos del proveedor.
Una vez que haya elegido el tema representado por una tabla, las columnas de dicha tabla solo
deberían almacenar datos sobre el tema. Por ejemplo, la tabla de productos debería almacenar
únicamente datos sobre los productos. Dado que la dirección del proveedor es un dato del proveedor
y no un hecho sobre el producto, esta pertenece a la tabla de proveedores.

Para determinar las columnas de una tabla, decida cuál es la información de la que necesita realizar un
seguimiento sobre el tema registrado en la tabla. Por ejemplo, para la tabla Clientes, una buena lista
inicial de columnas contendría Nombre, Dirección, Ciudad-Provincia-Código postal, Enviar correo
electrónico, Saludo y Dirección de correo electrónico. Cada registro de la tabla contiene el mismo
conjunto de columnas, por lo que puede almacenar la información de Nombre, Dirección, Ciudad-
Provincia-Código postal, Enviar correo electrónico, Saludo y Dirección de correo electrónico para cada
registro. Por ejemplo, la columna de dirección contiene las direcciones de los clientes. Cada registro
contiene datos sobre un cliente, y el campo dirección contiene la dirección de dicho cliente.
Una vez que haya determinado el conjunto inicial de columnas para cada tabla, podrá refinar aún más
las columnas. Por ejemplo, tiene sentido almacenar el nombre del cliente como dos columnas
separadas: nombre y apellidos, para que pueda ordenar, buscar e indexar en estas columnas. De forma
similar, la dirección realmente se compone de cinco componentes independientes: dirección, ciudad,
estado, código postal y país o región, que también tiene sentido almacenar en columnas separadas. Si
quiere realizar una búsqueda, filtrar u ordenar la operación por estado, por ejemplo, necesita que la
información de estado se almacene en una columna independiente.
También debería tener en cuenta si la base de datos contiene información solo de origen nacional o
también internacional. Por ejemplo, si va a almacenar direcciones internacionales, es mejor tener una
columna Región en lugar de Estado, ya que esa columna puede incluir tanto estados internos como
regiones de otros países o regiones. De forma similar, Código postal tiene más sentido que código ZIP
si va a almacenar direcciones internacionales.
En la lista siguiente se muestran 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 las tablas. En su
lugar, puede hacer que Access realice los cálculos cuando quiera ver el resultado. Por ejemplo,
suponga que hay un informe de Productos en pedidos que muestra el subtotal de unidades en
pedidos para cada categoría de producto en la base de datos. Pero no hay ninguna columna de
subtotal de Unidades en pedidos en ninguna tabla. En su lugar, la tabla Productos incluye una
columna Unidades en pedidos que almacena las unidades en pedidos para cada producto. Con esos
datos, Access calcula el subtotal cada vez que imprima el informe. El subtotal en sí no debería
almacenarse en una tabla.
Almacene la información en sus partes lógicas más pequeñas
Es posible que tenga la tentación de tener un solo campo para nombres completos o para nombres
de producto junto con descripciones de productos. Si 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 independientes para nombre y apellido, o para nombre,
categoría y descripción del producto.
Una vez ajustadas las columnas de datos de las tablas, ya puede elegir la clave principal de cada tabla.

Cada tabla debe incluir una columna (o conjunto de columnas) que identifique exclusivamente cada
fila almacenada en la tabla. Esto suele ser un número de identificación único, como un número de
identificación de empleado o un número de serie. En la terminología de base de datos, esta
información se denomina la clave principal de la tabla. Access usa los campos de clave principal para
asociar rápidamente los datos de varias tablas y agrupar esos datos.
Si ya tiene un identificador único para una tabla, como un número de producto que identifica
exclusivamente a cada producto en el catálogo, puede usar ese identificador como clave principal de
la tabla, pero solo si los valores de esta columna serán siempre diferentes para cada registro. No
puede tener valores duplicados en una clave principal. Por ejemplo, no use nombres de personas
como clave principal, porque los nombres no son únicos. Es muy fácil que dos personas tengan el
mismo nombre en una misma tabla.
Una clave principal siempre debe tener un valor. Si en algún momento el valor de una columna puede
quedar sin asignar o ser desconocido (un valor que falta), no se puede usar como un componente de
una clave principal.
Siempre debe elegir una clave principal cuyo valor no cambiará. En una base de datos que use más de
una tabla, la clave principal de una tabla puede usarse como referencia en otras tablas. Si se cambia la
clave principal, el cambio también se debe aplicar en todas partes en las que se hace referencia a la
clave. Usar una clave principal que no cambia reduce la posibilidad de que no se sincronice con otras
tablas que hacen referencia a ella.
A menudo se usa un número único arbitrario como clave principal. Por ejemplo, podría asignar a cada
pedido un número de pedido único. El único propósito del número de pedido es identificar un pedido.
Una vez asignado, nunca cambia.
Si no se le ocurre una columna o un conjunto de columnas que puedan servir como una buena clave
principal, considere la posibilidad de usar una columna que tenga el tipo de datos Autonumeración. Al
usar el tipo de datos Autonumeración, Access asigna automáticamente un valor por usted. Este
identificador está vacío, no contiene información objetiva sobre la fila que representa. Los
identificadores vacíos son ideales para usarlos como clave principal, porque no cambian. Una clave
principal que contiene datos sobre una fila, como el número de teléfono o el nombre de un cliente,
por ejemplo, es más probable que cambie, ya que la propia información objetiva podría cambiar.
1. Una columna establecida en el tipo de datos Autonumeración suele ser una buena clave principal.
No hay dos identificadores de producto iguales.
En algunos casos, tal vez quiera usar dos o más campos que, juntos, proporcionan la clave principal de
una tabla. Por ejemplo, una tabla de detalles de pedido que almacena datos de pedidos usaría dos
columnas en su clave principal: Identificador de pedido e Identificador de producto. Cuando una clave
principal está formada por más de una columna, también se denomina una clave compuesta.
Para la base de datos de ventas de productos, puede crear una columna Autonumeración para cada
una de las tablas para que sirvan de clave principal: Id. de producto para la tabla Productos, Id. de
pedido para la tabla Pedidos, Id. de cliente para la tabla Clientes e Id. de proveedor para la tabla
Proveedores.
Crear las relaciones de tablas

Ahora que ha dividido la información en tablas, necesita una manera para volver a unir la información
de forma que tenga significado. Por ejemplo, el siguiente formulario incluye información de varias
tablas.
1. La información de este formulario procede de la tabla Clientes...
2. ...la tabla Empleados...
3. ...la tabla Pedidos...
4. ...la tabla Productos...
5. ... y la tabla Detalles de pedidos.
Access es un sistema de administración de base de datos relacional. En una base de datos relacional,
se divide la información en tablas separadas, basadas en el temas. Después, se usan las relaciones de
la tabla para combinar la información según sea necesario.
Crear una relación uno a varios

Considere este ejemplo: las tablas Proveedores y Productos en la base de datos de pedidos de
productos. Un proveedor puede proporcionar cualquier cantidad de productos. Se puede decir que,
para cualquier proveedor que se representa en la tabla Proveedores, puede haber muchos productos
que se representan en la tabla Productos. La relación entre la tabla Proveedores y la tabla Productos
es, por tanto, una relación uno a varios.
Para representar una relación uno a varios en el diseño de la base de datos, tome la clave principal del
lado "uno" de la relación y agréguela como columna o columnas adicionales a la tabla en el lado
"varios" de la relación. En este caso, por ejemplo, agregaría la columna Id. de proveedor de la tabla
Proveedores a la tabla Productos. Así, Access puede usar el número de identificador del proveedor de
la tabla Productos para dar con el proveedor correcto de cada producto.
La columna Id. de proveedor en la tabla Productos se denomina una clave externa. Una clave externa
es la clave principal de otra tabla. La columna Id. de proveedor en la tabla Productos es una clave
externa porque también es la clave principal en la tabla Proveedores.
Al establecer parejas de claves principales y claves externas, proporciona la base para unir las tablas
relacionadas. Si no está seguro de qué tablas deberían compartir una columna común, identificar una
relación uno a varios asegura que, en efecto, las dos tablas relacionadas requerirán una columna
compartida.
Crear una relación de varios a varios

Considere la relación entre la tabla Productos y la tabla Pedidos.
Un solo pedido puede incluir varios productos. Por otra parte, un único producto puede aparecer en
muchos pedidos. Por tanto, por cada registro de la tabla Pedidos puede haber varios registros en la
tabla Productos. Además, por cada registro de la tabla Productos puede haber varios registros en la
tabla Pedidos. Este tipo de relación se denomina relación de varios a varios, porque, para cada
producto, puede haber varios pedidos, y para cada pedido puede haber muchos productos. Tenga en
cuenta que para detectar las relaciones de varios a varios entre las tablas, es importante que considere
ambas partes de la relación.
Entre los temas de las dos tablas, productos y pedidos, existe una relación de varios a varios. Esto
supone un problema. Para entender el problema, imagine qué pasaría si intentase crear la relación
entre las dos tablas agregando el campo Id. de producto a la tabla Pedidos. Para tener más de un
producto por pedido, necesita más de un registro por pedido en la tabla Pedidos. Tendría que repetir
la información del pedido en cada fila que esté relacionada con un único pedido, lo que provocaría un
diseño ineficaz que podría producir datos inexactos. Se encontraría con el mismo problema si colocase
el campo Id. de pedido en la tabla Productos: dispondrá de más de un registro en la tabla Productos
para cada producto. ¿Cómo se soluciona este problema?
La respuesta es crear una tercera tabla, a menudo denominada tabla de unión, que divida la relación
de varios a varios en dos relaciones uno a varios. Inserte la clave principal de cada una de las dos
tablas en la tercera tabla. Como resultado, la tercera tabla registra cada repetición o instancia de la
relación.
Cada registro de la tabla Detalles de pedidos representa un elemento de línea en un pedido. La clave
principal de la tabla Detalles de pedidos consta de dos campos: las claves externas de las tablas
Pedidos y Productos. Usar el campo de Id. de pedido por sí solo no sirve como clave principal para
esta tabla, porque un pedido puede tener muchos 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
de Id. de producto por sí solo tampoco sirve, porque un producto puede aparecer en varios pedidos
diferentes. Pero juntos, los dos campos siempre generan un valor único para cada registro.
En la base de datos de ventas de productos, la tabla Pedidos y la tabla Productos no están

directamente relacionadas entre sí. En su lugar, están relacionadas indirectamente a través de la tabla
Detalles de pedidos. La relación de varios a varios entre productos y pedidos se representa en la base
de datos mediante dos relaciones de uno a varios:
La tabla Pedidos y la tabla Detalles de pedidos tienen una relación de uno a varios. Cada pedido
puede tener más de un elemento de línea, pero cada elemento de línea está conectado a un único
pedido.
La tabla Productos y la tabla Detalles de pedidos tienen una relación de uno a varios. Cada
producto puede tener muchos elementos de línea asociados a él, pero cada elemento de línea se
refiere a un solo producto.
En la tabla Detalles de pedido, puede determinar todos los productos en un pedido determinado.
También puede determinar todos los pedidos de un producto en particular.
Después de incorporar la tabla Detalles de pedido, la lista de tablas y campos podría tener un aspecto
similar a este:
Crear una relación uno a uno

Otro tipo de relación es la relación de uno a uno. Por ejemplo, supongamos que necesita registrar
información adicional sobre productos que casi nunca necesitará o que solo se aplica a unos pocos
productos. Puesto que no necesita la información con frecuencia, y que almacenar la información de la
tabla Productos daría como resultado un hueco en todos los productos a los que no se aplica, la
coloca en una tabla aparte. Al igual que la tabla Productos, puede usar el Id. de producto como clave
principal. La relación entre esta tabla y la tabla Productos es una relación de uno a uno. Para cada
registro de la tabla Producto, existe un único registro coincidente en la tabla complementaria. Cuando
se identifica este tipo de relación, ambas tablas deben compartir un campo común.
Al detectar la necesidad de una relación de uno a uno en la base de datos, tenga en cuenta si se
puede combinar la información de las dos tablas en una sola. Si por algún motivo no quiere hacerlo,
quizás porque se crearía una gran cantidad de huecos, la siguiente lista le muestra cómo puede
representar la relación en su diseño:
Si las dos tablas tienen el mismo tema, probablemente pueda configurar la relación usando la
misma clave principal en ambas tablas.
Si las dos tablas tienen diferentes temas con diferentes claves principales, elija una de las tablas
(cualquiera de ellas) e inserte la clave principal de 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 de uno a uno o uno a varios, las tablas relacionadas tienen que
compartir una o varias columnas comunes. Cuando existe una relación varios a varios, se necesita una
tercera tabla para representar la relación.
Refinar el diseño
Una vez que tiene las tablas, campos y relaciones que necesita, debería crear y rellenar las tablas con
datos de ejemplo e intentar trabajar con la información: creando consultas, agregando nuevos
registros, etc. Esto le permitirá resaltar los posibles problemas. Por ejemplo, tal vez deba agregar una
columna que olvidó insertar durante la fase de diseño, y es posible que tenga una tabla que debería
dividir en dos tablas para eliminar los datos duplicados.
Vea si puede usar la base de datos para obtener las respuestas que quiere. Cree bocetos de los
formularios e informes y compruebe si muestran los datos que espera. Busque duplicaciones de datos
innecesarias y, si encuentra alguna, modifique el diseño para eliminarla.
Cuando pruebe la base de datos inicial, probablemente descubrirá posibilidades de mejora. Estas son
algunas cosas que debería comprobar:
¿Olvidó alguna columna? Si es así, ¿la información pertenece a las tablas existentes? Si se trata de
información sobre otra cosa, tal vez necesite crear otra tabla. Cree una columna para cada elemento
de información del que necesite realizar un seguimiento. Si no se puede calcular la información de
otras columnas, es probable que necesite una nueva columna para ella.
¿Cualquiera de las columnas innecesarias lo son porque se pueden calcular con los campos
existentes? Si se puede calcular un elemento de información desde otras columnas existentes, como
por ejemplo, un precio de descuento calculado a partir del precio de venta, generalmente es mejor
simplemente hacerlo y evitar crear una nueva columna.
¿Ha introducido información duplicada en una de las tablas? Si es así, probablemente tenga que
dividir la tabla en dos tablas que tengan una relación de 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 rediseñ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 realizar
informes, ordenar, buscar o calcular sobre un elemento de información, coloque dicho elemento en
su propia columna.
¿Cada columna contiene datos sobre el tema de la tabla? Si una columna no contiene información
sobre el tema de la tabla, pertenece a otra tabla.
¿Las relaciones son entre las tablas representadas, bien sea por los campos comunes o por una
tercera tabla? Las relaciones de uno a uno y de uno a varios requieren columnas comunes. Las
relaciones de varios a varios requieren una tercera tabla.
Ajustar la tabla Productos.

Suponga que cada producto en la base de datos de ventas de productos se encuentra en una
categoría general, como bebidas, condimentos o marisco. La tabla Productos podría incluir un campo
que muestre la categoría de cada producto.
Suponga que, después de examinar y refinar el diseño de la base de datos, decide almacenar una
descripción de la categoría junto con su nombre. Si agrega un campo Descripción de la categoría a la
tabla Productos, tendrá que repetir la descripción de cada categoría para cada producto en el que se
encuentre dentro de la categoría, lo que no es una buena solución.
Una solución mejor es convertir Categorías en un nuevo tema de la base de datos para realizar el
seguimiento, con su propia tabla y su propia clave principal. Después, podrá agregar la clave principal
de la tabla Categorías a la tabla Productos como clave externa.
Las tablas Categorías y Productos tienen una relación de uno a varios: una categoría puede contener
más de un producto, pero un producto pertenece únicamente a una categoría.
Al revisar las estructuras de tabla, esté atento a los grupos que se repiten. Por ejemplo, considere la
posibilidad de una tabla que contiene las siguientes columnas:
Id. de producto
Nombre
Id. de producto1
Nombre1
Id. de producto2
Nombre2
Id. de producto3
Nombre3
Aquí, cada producto es un grupo de columnas que se repite y que difiere de los demás solo porque
agrega un número al final del nombre de columna. Si ve columnas numeradas de esta forma, debería
revisar el diseño.
Este tipo de diseño tiene varios defectos. Para empezar, lo obliga a poner un límite superior en el
número de productos. En cuanto supere ese límite, deberá agregar un nuevo grupo de columnas a la
estructura de la tabla, lo que implica más tareas administrativas.
Otro problema es que los proveedores que tienen menos del número máximo de productos
desperdiciarán el espacio, ya que las columnas adicionales estarán en blanco. El defecto más grave de
este diseño es que hace que muchas tareas sean difícil de realizar, como ordenar o indexar la tabla por
Id. de producto o nombre.
Siempre que vea grupos que se repiten, revise cuidadosamente el diseño y esté pendiente sobre cómo
dividir la tabla en dos. En el ejemplo anterior, es mejor usar dos tablas, una para proveedores y otra
para productos, vinculadas por Id. de proveedor.

Puede aplicar las reglas de normalización de datos (a veces se denominan reglas de normalización)
como el siguiente paso en su diseño. Dichas reglas se usan para ver si las tablas están estructuradas
correctamente. El proceso de aplicar las reglas al diseño de la base de datos se denomina
normalización de la base de datos, o simplemente, normalización.
La normalización es especialmente útil después de representar todos los elementos de información y

cuando ya tenga un diseño preliminar. La idea es ayudarle a asegurarse de que se han dividido los
elementos de información en las tablas apropiadas. Lo que la normalización no puede hacer es
asegurarse de que tiene todos los elementos de los datos correctos con los que comenzar.
En cada paso, aplica las reglas consecutivamente, para garantizar que su diseño llegue a tener lo que
se denomina "formulario normal". En general, se aceptan cinco formularios normales, del primer
formulario normal al quinto formulario normal. Este artículo se centra en los tres primeros, ya que son
todo lo necesario para la mayoría de los diseños de base de datos.
Primer formulario normal

El primer formulario normal indica que, en cada intersección de fila y columna de la tabla, existe un
valor único y nunca una lista de valores. Por ejemplo, no puede tener un campo denominado Precio
en el que coloca más de un precio. Si piensa en cada intersección de filas y columnas como en una
celda, cada celda puede contener un solo valor.
Segundo formulario normal

El segundo formulario normal requiere que cada columna de clave dependa completamente de toda
la clave principal y no solo de parte de la clave. Esta regla se aplica cuando tiene una clave principal
que consta de más de una columna. Por ejemplo, supongamos que tiene una tabla que contiene las
siguientes columnas, donde el Id. de pedido y el Id. de producto forman la clave principal:
Id. de pedido (clave principal)
Id. de producto (clave principal)
Nombre del producto
Este diseño infringe el segundo formulario normal, porque el Nombre de producto depende del Id. de
producto, pero no del Id. de pedido, por lo que no depende de toda la clave principal. Debe quitar
Nombre de producto de la tabla. Pertenece a una tabla diferente (Productos).
Tercer formulario normal

El tercer formulario normal requiere que no solo cada columna de clave dependa de toda la clave
principal, sino también que las columnas que no son claves sean independientes entre sí.
Otra forma de decirlo es que cada columna que no sea de clave debe depender de la clave principal y
nada más que de la clave principal. Por ejemplo, suponga que tiene una tabla que contiene las
siguientes columnas:
Id. de producto (clave principal)
Nombre
PVS
Descuento
Suponga que Descuento depende del precio de venta sugerido (PVS). Esta tabla infringe el tercer
formulario normal porque una columna que no es de clave, Descuento, depende de otra columna sin
clave, PVS. La independencia de columna significa que debería poder cambiar cualquier columna sin
clave sin que afecte a cualquier otra columna. Si cambia un valor en el campo PVS, el descuento
cambiaría en consecuencia, por tanto infringiría esa regla. En este caso Descuento se moverá a otra
tabla cuya clave sea PVS.

Conceptos Básicos Acces

Cargado por

Información del documento

Título original

Derechos de autor

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Conceptos Básicos Acces

Título original:

Cargado por

Copyright:

3/5/2021 Conceptos básicos del diseño de una base de datos - Access

Conceptos básicos del diseño de una

Importante: Access proporciona experiencias de diseño que le permiten crear aplicaciones de bases de

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

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 las claves principales

Crear las relaciones de tablas

Aplicar las reglas de normalización

Algunos términos de base de datos que debe conocer

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

Un buen diseño de base de datos es, por tanto, aquel que:

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

Se ajusta a sus necesidades de informes y procesamiento de datos.

Determinar el propósito de la base de datos

Esto le ayudará a prepararse para los pasos restantes.

Buscar y organizar la información necesaria

Dividir la información en tablas

Convertir los elementos de información en columnas

Especificar las claves principales

Establecer las relaciones de tablas

Aplicar las reglas de normalización

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

En la lista siguiente se muestran algunas sugerencias para determinar las columnas.

No incluya datos calculados

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

Especificar las claves principales

Crear las relaciones de tablas

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

2. ...la tabla Empleados...

3. ...la tabla Pedidos...

4. ...la tabla Productos...

5. ... y la tabla Detalles de pedidos.

Crear una relación uno a varios

Crear una relación de varios a varios

En la base de datos de ventas de productos, la tabla Pedidos y la tabla Productos no están

Crear una relación uno a uno

Ajustar la tabla Productos.

Aplicar las reglas de normalización

La normalización es especialmente útil después de representar todos los elementos de información y

Primer formulario normal

Segundo formulario normal

Id. de pedido (clave principal)

Id. de producto (clave principal)

Nombre del producto

Tercer formulario normal

Id. de producto (clave principal)

Intereses relacionados

También podría gustarte