Tutorial de estructura y diseño de bases de datos

¿Cuáles son tus necesidades de creación de diagramas de base de datos?

No tengo experiencia en diagramas de base de datos y quiero aprender más.

Quiero crear mi propio diagrama de base de datos en Lucidchart.

Quiero crear un diagrama de base de datos usando una plantilla de Lucidchart.

Índice

 El proceso de diseño de base de datos

 Análisis de los requisitos: identificar el propósito de la base de datos
 Estructura de la base de datos: los bloques de creación de una base de datos
 Creación de relaciones entre entidades
 Normalización de la base de datos
 Datos multidimensionales
 Reglas de integridad de datos
 Agregar índices y visualizaciones
 Propiedades extendidas
 SQL y UML
 Sistemas de gestión de bases de datos
Una base de datos bien diseñada brinda a los usuarios acceso a información fundamental. Al seguir
los principios de esta página, puedes diseñar una base de datos que funcione bien y se adapte a
tus necesidades futuras. Explicaremos los aspectos básicos sobre el diseño de una base de datos y
cómo perfeccionarlo para obtener resultados óptimos.

15 minutos de lectura

¿Deseas crear tu propio diagrama de base de datos? Prueba Lucidchart. Es rápido, sencillo y
totalmente gratis.

Genera un diagrama de base de datos

El proceso de diseño de base de datos

Una base de datos bien estructurada:

 Ahorra espacio en el disco eliminando los datos redundantes.

 Mantiene la precisión e integridad de los datos.

  Ofrece acceso a los datos de formas útiles.

Diseñar una base de datos útil y eficiente requiere seguir el proceso adecuado, incluidas las
siguientes etapas:

1. Análisis de los requisitos o identificación del propósito de tu base de datos.

2. Organización de los datos en tablas.

3. Especificación de las claves primarias y análisis de las relaciones.

4. Normalización para estandarizar las tablas.

Realicemos un análisis detallado de cada paso. Ten en cuenta que esta guía se centra en el modelo
de base de datos relacional de Edgar Codd escrito en SQL (en lugar de modelos jerárquicos, de red
o de datos de objetos). Para saber más sobre los modelos de base de datos, lee nuestra guía aquí.

Análisis de los requisitos: identificar el propósito de la base de datos

Comprender el propósito de tu base de datos determinará tus opciones en todo el proceso de

diseño. Asegúrate de observar la base de datos desde todas las perspectivas. Por ejemplo, si
estuvieras creando una base de datos para una biblioteca pública, deberías considerar las formas
en que los clientes y bibliotecarios necesitarían acceder a los datos.

Aquí te mostramos algunas formas de reunir información antes de crear la base de datos:

 Entrevistar a las personas que la usarán.

 Analizar formularios de negocio, como facturas, plantillas de horas trabajadas, encuestas.

 Examinar cualquier sistema de datos existente (incluidos archivos físicos y digitales).

Comienza reuniendo cualquier dato existente que se incluirá en la base de datos. Luego enumera
los tipos de datos que quieres almacenar y las entidades o personas, cosas, ubicaciones y eventos
que esos datos describen, del siguiente modo:

Clientes

 Nombre

 Dirección

 Ciudad, estado, código postal

 Dirección de correo electrónico

Productos

 Nombre

 Precio

 Cantidad en stock

 Cantidad en el pedido
Pedidos

 Número del pedido

 Representante de ventas

 Fecha

 Producto(s)

 CANTIDAD

 Precio

 Total

Más adelante, esta información se volverá parte del directorio de datos, que describe las tablas y
los campos dentro de la base de datos. Asegúrate de dividir la información en partes útiles lo más
pequeñas posibles. Por ejemplo, considera separar el nombre de la calle del país para poder filtrar
más adelante a los individuos según su país de residencia. Además, evita ubicar el mismo punto de
datos en más de una tabla porque agregarás una complejidad innecesaria.

Cuando sepas qué tipos de datos incluirán las bases de datos, de dónde provienen esos datos y
cómo se usarán, estarás listo para comenzar a planificar la base de datos real.

Estructura de la base de datos: los bloques de creación de una base de datos

El siguiente paso es organizar la representación visual de tu base de datos. Para ello, debes
comprender exactamente cómo se estructuran las bases de datos relacionales.

Dentro de una base de datos, los datos relacionados se agrupan en tablas, cada una de ellas
consiste en filas (también llamadas "tuplas") y columnas, como una hoja de cálculo.

Para convertir tus listas de datos en tablas, comienza creando una tabla para cada tipo de entidad,
como productos, ventas, clientes y pedidos. Te mostramos un ejemplo a continuación:

Cada fila de una tabla se llama "registro". Los registros incluyen datos sobre algo o alguien, como
un cliente específico. En cambio, las columnas (también conocidas como "campos" o "atributos")
contienen un único tipo de información que aparece en cada registro, como las direcciones de
todos los clientes enumerados en la tabla.

Nombre Apellido Edad Código postal

Roger Williams 43 34760

Jerrica Jorgensen 32 97453

Samantha Hopkins 56 64829

Con el fin de que los datos sean consistentes de un registro al siguiente, asigna el tipo de datos
apropiado a cada columna. Los tipos de datos comunes incluyen:

 CHAR - una longitud específica de texto.

 VARCHAR - texto de longitudes variables.

 TEXT - grandes cantidades de texto.

 INT - número entero positivo o negativo.

 FLOAT, DOUBLE - también puede almacenar números de punto flotante.

 BLOB - datos binarios.

Algunos sistemas de gestión de bases de datos también ofrecen el tipo de datos denominado
"Autonumeración", que genera automáticamente un número único en cada fila.

A los efectos de crear una visión general de la base de datos, conocida como un diagrama entidad-
relación, no incluiremos las tablas reales, sino que cada tabla se convertirá en un recuadro del
diagrama. El título de cada recuadro debería indicar qué describen los datos en la tabla, mientras
que los atributos están enumerados a continuación, del siguiente modo:

Por último, deberías decidir qué atributo o atributos funcionarán como clave primaria para cada
tabla, si procede. Una clave primaria (PK) es un identificador único para una entidad determinada,
esto significa que puedes seleccionar un cliente concreto incluso si solo conoces ese valor.

Los atributos seleccionados como claves primarias deben ser únicos, inalterables y estar siempre
presentes (nunca NULL o vacíos). Por este motivo, los números de pedido y los nombres de usuario
son excelentes claves primarias, mientras que los números de teléfono o direcciones postales no lo
son. También puedes usar múltiples campos conjuntamente como la clave primaria (esto se
denomina "clave compuesta").

Cuando llegue el momento de crear la base de datos real, ubicarás la estructura de datos lógicos y
la estructura de datos físicos en el lenguaje de definición de datos admitido por nuestro sistema de
gestión de base de datos. En este punto, también deberías calcular el tamaño aproximado de la
base de datos para asegurarte de tener el nivel de rendimiento y el espacio de almacenamiento
necesarios.

Creación de relaciones entre entidades

Cuando tus tablas de base de datos se conviertan en tablas, estarás listo para analizar las
relaciones entre esas tablas. La cardinalidad se refiere a la cantidad de elementos que interactúan
entre dos tablas relacionadas. Identificar la cardinalidad te ayuda a asegurarte de que has dividido
los datos en tablas de la forma más eficiente.
Cada entidad puede, potencialmente, tener una relación con todas las demás, pero por lo general
esas relaciones pueden ser de uno de tres tipos:

Relaciones uno a uno

Si hay una única instancia de la Entidad A para cada instancia de la Entidad B, se dice que tienen
una relación de uno a uno (a menudo se escribe 1:1). Puedes indicar este tipo de relación en un
diagrama ER mediante una línea con un guión en cada extremo:

A menos que tengas un buen motivo para no hacerlo, una relación 1:1 generalmente indica que la
mejor opción sería combinar los datos de las dos tablas en una sola tabla.

Sin embargo, quizás desees crear tablas con una relación de uno a uno en una serie particular de
circunstancias. Si tienes un campo con datos opcionales, como "descripción", que está en blanco
para muchos registros, puedes mover todas las descripciones a su propia tabla, eliminando espacio
vacío y mejorando el rendimiento de la base de datos.

Para garantizar que los datos coincidan correctamente, luego tendrías que incluir al menos una
columna idéntica en cada tabla, lo más probable es que sea la clave primaria.

Relaciones uno a muchos

Estas relaciones suceden cuando un registro de una tabla está asociado a múltiples entradas en
otra tabla. Por ejemplo, un solo cliente puede haber solicitado múltiples pedidos o una persona
haberse llevado muchos libros de la biblioteca a la vez. Las relaciones uno a muchos (1:M) se
indican con lo que se denomina "notación patas de gallo" como en el siguiente ejemplo:

Para implementar una relación uno a muchos (1:M) mientras preparas una base de datos,
simplemente agrega la clave primaria de "un" lado de la relación como un atributo en la otra tabla.
Cuando una clave primaria se detalla en otra tabla de esta manera, se denomina "clave
extranjera". La tabla en el lado "1" de la relación es considerada una tabla principal respecto de la
tabla secundaria que se encuentra del otro lado.

Relaciones muchos a muchos

Cuando múltiples entidades de una tabla se pueden asociar a múltiples entidades de otra tabla, se
dice que tienen una relación de muchos a muchos (M:N). Esto puede suceder en el caso de
estudiantes y clases, ya que un estudiante puede inscribirse en muchas clases, y una clase puede
tener numerosos estudiantes.

En un diagrama ER, estas relaciones se representan con estas líneas:

Lamentablemente, no es posible implementar directamente este tipo de relación en una base de
datos. En cambio, debes dividirlo en dos relaciones uno a muchos.

Para ello, debes crear una nueva entidad entre esas dos tablas. Si la relación M:N existe entre
ventas y productos, quizás llames a esa nueva entidad "productos_vendidos", ya que mostraría los
contenidos de cada venta. Tanto las tablas de ventas como de productos tendrían una relación 1:M
con "productos_vendidos". Esta clase de entidad intermedia se llama "tabla de enlaces", "entidad
asociativa" o "tabla de unión" en diversos modelos.

Cada registro de la tabla de enlaces se correspondería con dos de las entidades de las tablas
contiguas (también puede incluir información adicional). Por ejemplo, una tabla de enlaces entre
estudiantes y clases podría verse así:

¿Es obligatorio o no?

Otra forma de analizar las relaciones es considerar qué lado de la relación debe existir para que el
otro lado exista. El lado no obligatorio puede marcarse con un círculo en la línea donde debería
haber un guión. Por ejemplo, un país tiene que existir para tener un representante en las Naciones
Unidas, pero lo opuesto no se cumple:

Dos entidades pueden ser mutuamente dependientes (una no podría existir sin la otra).

Relaciones recursivas

A veces una tabla se relaciona consigo misma. Por ejemplo, una tabla de empleados puede tener
un atributo que sea "director" y que se refiera a otro individuo de la misma tabla. Esto se llama
"relación recursiva".

Relaciones redundantes

Una relación redundante es aquella que se expresa más de una vez. Por lo general, puedes
eliminar una de las relaciones sin perder información importante. Por ejemplo, si la entidad
"estudiantes" tiene una relación directa con otra entidad llamada "profesores", pero también tiene
una relación con profesores indirectamente mediante "clases", querrás eliminar la relación entre
"estudiantes" y "profesores". Es mejor eliminar esa relación porque la única forma de que los
estudiantes se asignan a los profesores es mediante las clases.

Normalización de la base de datos

Una vez que tengas un diseño preliminar para tu base de datos, puedes aplicar reglas de
normalización para asegurarte de que las tablas estén estructuradas correctamente. Piensa en
estas reglas como los estándares de la industria.

Dicho esto, no todas las bases de datos son buenas candidatas para la normalización.
Generalmente, las bases de datos de procesamiento de transacciones en línea (OLTP), en las que
los usuarios se encargan de la creación, lectura, actualización y eliminación de los registros,
deberían estar normalizadas.

Las bases de datos de procesamiento analítico en línea (OLAP) que favorecen el análisis y la
generación de informes funcionarían mejor con un grado de desnormalización, ya que el énfasis
está en la velocidad de cálculo. Estas incluyen aplicaciones de soporte de decisiones en las que los
datos se deben analizar rápidamente, pero no deben modificarse.

Cada forma, o nivel de normalización, incluye las reglas asociadas a las formas inferiores.

La primera forma normal

La primera forma normal (abreviada como "1FN") especifica que cada celda de la tabla puede
tener un solo valor, nunca una lista de valores. Por lo tanto, una tabla como esta no cumple con los
requisitos:

ID del producto Color Precio

1 marrón, amarillo $15

2 rojo, verde $13

3 azul, naranja $11

Quizás pienses que la mejor solución sea dividir los datos en columnas adicionales, pero eso
también rompería las reglas: una tabla con grupos de atributos repetidos o estrechamente
relacionados entre sí no cumple con la primera forma normal. Por ejemplo, la tabla a continuación
no cumple con los requisitos:

En cambio, divide los datos en múltiples tablas o registros hasta que cada celda contenga solo un
valor y no halla columnas adicionales. En este punto, se dice que los datos son "atómicos", es decir
que se dividen en partes útiles lo más pequeñas posibles. Para la tabla anterior, podrías crear una
tabla adicional llamada "Datos de ventas", que haría coincidir productos específicos con ventas.
Así, "Ventas" tendría una relación 1:M con "Datos de ventas".

La segunda forma normal

La segunda forma normal (2NF) establece que todos los atributos deben ser totalmente
dependientes de toda la clave primaria. Eso significa que cada atributo debería depender
directamente de la clave primaria, en lugar de indirectamente a través de algún otro atributo.
Por ejemplo, se considera que el atributo "edad" que depende de "fecha de nacimiento", que a su
vez depende de "ID de estudiante" tiene una dependencia funcional parcial; y una tabla que
contenga estos atributos no cumpliría con la segunda forma normal.

Además, una tabla con una clave primaria compuesta de múltiples campos viola la segunda forma
normal si uno o más de los otros campos no dependen de cada parte de la clave.

Por lo tanto, una tabla con estos campos no respetaría la segunda forma normal porque el atributo
"Nombre del producto" depende del ID del producto, pero no del número de pedido:

 Número de pedido (clave primaria)

 ID de producto (clave primaria)

 Nombre del producto

La tercera forma normal

La tercera forma normal (3NF) agrega a estas reglas el requisito de que cada columna que no sea
de clave sea independiente de las demás columnas. Si modificar el valor en una columna que no
sea de clave hace que cambie otro valor, entonces esa tabla no cumple con los requisitos de la
tercera forma normal.

Esto evita que almacenes cualquier dato derivado en la tabla, tal como la columna "Impuestos" a
continuación, que depende directamente del precio final del pedido:

Pedido Precio Impuestos

14325 $40.99 $2.05

14326 $13.73 $.69

14327 $24.15 $1.21

Se han propuesto formas adicionales de normalización, incluidas la forma normal de Boyce-Codd,

la cuarta, quinta y sexta forma normal, y la forma normal de dominio/clave, pero las primeras tres
son las más comunes.

Si bien estas formas explican las buenas prácticas que se deben seguir generalmente, el grado de
normalización depende del contexto de la base de datos.

¿Deseas crear tu propio diagrama de base de datos? Prueba Lucidchart. Es rápido, sencillo y
totalmente gratis.

Genera un diagrama de base de datos

Datos multidimensionales

Algunos usuarios quizás deseen acceder a múltiples dimensiones de un único tipo de dato,
especialmente en las bases de datos OLAP. Por ejemplo, quizás deseen conocer las ventas por
cliente, estado y mes. En esta situación, lo mejor es crear una tabla de datos central que actúe de
referencia para las otras tablas de cliente, estado y mes, de este modo:

Reglas de integridad de datos

También deberías configurar tu base de datos para validar los datos en función de las reglas
adecuadas. Muchos sistemas de gestión de base de datos, como Microsoft Access, ejecutan
automáticamente algunas de estas reglas.

La regla de integridad de la entidad afirma que la clave primaria nunca puede ser NULL. Si la clave
está compuesta por múltiples columnas, ninguna de ellas puede ser NULL. De lo contrario, podría
no identificar de forma única al registro.

La regla de la integridad referencial requiere que cada clave externa que aparece en una tabla se
corresponda con una clave primaria de la tabla a la que hace referencia. Si la clave primaria cambia
o se elimina, esos cambios deberán implementarse donde sea que esté la referencia a esa clave en
toda la base de datos.

Las reglas de la integridad lógica de negocios garantizan que los datos se adecúen a determinados
parámetros lógicos. Por ejemplo, el horario de una cita deberá fijarse dentro de las horas laborales
normales.

Agregar índices y visualizaciones

Un índice es, en esencia, una copia ordenada de una o más columnas, con valores dispuestos de
forma ascendente o descendente. Agregar un índice permite a los usuarios encontrar los registros
más rápidamente. En lugar de reordenar cada consulta, el sistema puede acceder a los registros en
el orden que especifica el índice.

Si bien los índices aceleran la recuperación de datos, pueden enlentecer la inserción, actualización
o eliminación, ya que el índice debe rediseñarse cada vez que se modifica un registro.

Una visualización es simplemente una consulta almacenada sobre los datos. Puede unir datos de
múltiples tablas de manera útil o bien mostrar parte de una tabla.

Propiedades extendidas

Una vez que hayas finalizado la disposición básica, puedes refinar la base de datos con propiedades
extendidas, como el texto instructivo, la máscara de entrada y las reglas de formato que se aplican
a un esquema, visualización o columna determinada. La ventaja es que, como estas reglas están
almacenadas en la misma base de datos, la presentación de los datos será consistente en todos los
programas que accedan a los mismos.

SQL y UML
El lenguaje unificado de modelado (UML) es otra forma visual de expresar sistemas complejos
creados en un lenguaje orientado a objetos. Muchos de los conceptos mencionados en esta guía se
conocen en UML con distintos nombres. Por ejemplo, una entidad se llama "clase" en UML.

Hoy en día no se usa el UML con tanta frecuencia como antes. En la actualidad, se emplea en
entornos académicos y en las comunicaciones entre diseñadores de software y sus clientes.

Sistemas de gestión de bases de datos

Muchas de las elecciones de diseño que tomarás dependen del sistema de gestión de base de
datos que elijas. Algunos de los sistemas más comunes incluyen:

 Oracle DB

 MySQL

 Microsoft SQL Server

 PostgreSQL

 IBM DB2

Cuando puedas elegir, selecciona un sistema de gestión de base de datos en función del costo, los
sistemas operativos, las funciones y más.

Recursos útiles

 Qué es un esquema de base de datos

 Qué es un modelo de base de datos
Cuando estés listo para empezar a diseñar tu base de datos, prueba la herramienta de diagrama
entidad-relación de Lucidchart. Después de importar cualquier SQL, simplemente usa el método de
arrastrar y soltar para crear tablas y luego especifica las relaciones con un clic. Inicia tu prueba
gratuita hoy mismo.

¿Deseas crear tu propio diagrama de base de datos? Prueba Lucidchart. Es rápido, sencillo y
totalmente gratis.

Genera un diagrama de base de datos

Empezar ahora

 Precios
 Individual
 Equipo
 Corporativo
 Comunícate con Ventas
Producto

 Un vistazo a Lucidchart
 Lucidscale
 Integraciones
 Seguridad
Casos de uso

 Documentación de sistemas y arquitectura

 Creación de diagramas técnicos
 Visualización de organizaciones y equipos Ágiles
 Crear mapas de procesos y diagramas de flujo
Recursos

 Campus de Aprendizaje
 Blog
 Soporte Técnico
 Casos de Éxito
 Biblioteca de diagramas
 Socios
Empresa

 Quiénes somos
 Misión
 Liderazgo
 Sala de prensa
 Empleo
Español

PrivacidadLegalOpciones de privacidad de cookiesPolítica de cookies


