De la realidad a la información: diseño de bases de datos del modelo entidad–relación al modelo relacional

Resumen

El diseño de una base de datos empieza antes de abrir un programa para crear tablas. Debemos observar la realidad, reconocer un problema, seleccionar los datos importantes y construir una representación comprensible. En este artículo aprenderás a transformar una situación cotidiana en un Modelo Entidad–Relación (MER) y, posteriormente, en un diagrama relacional con tablas y claves.

Artículo académico-didáctico para estudiantes de Educación Media Superior, Técnico en Ofimática, Módulo 4. Palabras clave: análisis, abstracción, entidad, instancia, atributo, relación, cardinalidad, clave primaria, clave foránea, MER y modelo relacional.

1. Introducción: ¿cómo pasamos de la realidad a la información?

Cuando una escuela inscribe alumnos, presta equipos, asigna grupos o registra calificaciones, ocurren acontecimientos que producen datos. Una base de datos permite organizar y consultar esos datos para responder preguntas concretas.

Por ejemplo, el responsable de un laboratorio necesita saber qué estudiante recibió una computadora, cuándo se la prestaron y si ya la devolvió. El objetivo no es guardar cualquier información, sino la que resulta útil para atender una necesidad.

Ruta de trabajo: REALIDAD → ANÁLISIS → ABSTRACCIÓN → MODELO ENTIDAD–RELACIÓN → MODELO RELACIONAL → IMPLEMENTACIÓN.

Antes de continuar, puedes repasar la diferencia entre datos, información, archivos y bases de datos en el artículo «Conceptos básicos de bases de datos».

Video explicativo: de la realidad al Modelo Relacional

Para complementar la lectura, observa esta explicación audiovisual del proceso que transforma una situación real en un MER y luego en tablas relacionadas con claves primarias y foráneas.

Si el reproductor no aparece en tu dispositivo, abre el video directamente en YouTube.

2. Primer paso: analizar la situación real

Imaginemos que en el laboratorio del CBTa se lleva una libreta de préstamos de computadoras. Cada solicitud se anota manualmente. Si un alumno tarda en devolver el equipo, buscar su registro podría ser complicado. La institución necesita una base de datos para administrar los préstamos.

El análisis de requerimientos consiste en observar cómo funciona la actividad, identificar quién participa, qué información se produce y qué consultas se desean realizar.

• ¿Quién solicita los equipos? Los alumnos.

• ¿Qué se presta? Computadoras y otros equipos.

• ¿Qué operación necesitamos controlar? Cada préstamo.

• ¿Qué datos debemos conservar? Identificación del estudiante, equipo, fecha de salida y fecha de devolución.

Nuestro problema queda definido: registrar los préstamos de equipos de cómputo para consultar su historial y conocer los equipos pendientes de devolución.

3. Segundo paso: abstraer la realidad

Abstraer significa seleccionar las características relevantes de una situación y descartar aquellas que no contribuyen a la solución. Por ejemplo, el color favorito de un alumno no es necesario para registrar un préstamo; su número de control sí puede serlo.

La situación particular «Luis Pérez recibió una laptop Lenovo el 1 de octubre» se convierte en una descripción general: «Un ALUMNO realiza un PRÉSTAMO de un EQUIPO». Esta frase sirve para representar muchos casos, no solamente el de Luis.

La abstracción es fundamental porque nos permite pasar de personas y objetos concretos a categorías de información.

4. Tercer paso: identificar entidades e instancias

Una entidad es una clase de personas, objetos, acontecimientos o conceptos de la que necesitamos almacenar datos. Una instancia es un elemento particular de una entidad.

• ALUMNO es una entidad; Luis Pérez y Ana López son instancias.

• EQUIPO es una entidad; la laptop identificada como EQ001 es una instancia.

• PRÉSTAMO es una entidad que representa un acontecimiento; el préstamo 501 es una instancia.

En el Modelo Entidad–Relación tradicional de Peter Chen, las entidades se representan mediante rectángulos y generalmente reciben nombres en singular.

Para profundizar en qué es una entidad y cómo se representa, consulta «Modelo Entidad–Relación: guía práctica para diseñar una base de datos».

5. Cuarto paso: elegir atributos

Un atributo es una característica que describe una entidad. Cada atributo tendrá un valor distinto para cada instancia, según corresponda.

• ALUMNO: NumControl, Nombre y Grupo.

• EQUIPO: IdEquipo, Tipo y Marca.

• PRÉSTAMO: IdPrestamo, FechaSalida y FechaDevolucion.

Ejemplo de ALUMNO: NumControl = 1001; Nombre = Luis Pérez; Grupo = 4.º A Ofimática. Los nombres de las características son atributos; sus contenidos, como 1001 o Luis Pérez, son valores de datos.

En la notación de Chen, los atributos suelen representarse mediante óvalos conectados a la entidad.

Si aún tienes dudas sobre atributo, dato, registro o tabla, vuelve al tema «Conceptos básicos de bases de datos» antes de avanzar.

6. Quinto paso: asignar claves primarias

Una clave primaria, denominada Primary Key (PK), es un atributo o conjunto mínimo de atributos que permite identificar de manera única cada registro.

Dos alumnos pueden llamarse Luis Pérez, pero no deberían compartir el mismo número de control si este fue definido como identificador único. Por eso elegimos NumControl como PK de ALUMNO.

• ALUMNO: NumControl (PK).

• EQUIPO: IdEquipo (PK).

• PRÉSTAMO: IdPrestamo (PK).

Una clave primaria debe ser única, no debe ser nula y conviene que sea estable. En diseños más avanzados también puede construirse a partir de varias columnas.

7. Sexto paso: identificar las relaciones

Una relación es una asociación entre entidades. Puede expresarse mediante verbos: un ALUMNO REALIZA un PRÉSTAMO; un PRÉSTAMO INCLUYE un EQUIPO.

En el MER de Chen, la relación se representa con un rombo conectado a los rectángulos de las entidades. El nombre del rombo suele ser un verbo que explica la asociación.

Los símbolos y la construcción de relaciones se estudian con ejemplos en «Modelo Entidad–Relación: guía práctica para diseñar una base de datos».

8. Séptimo paso: determinar la cardinalidad

La cardinalidad indica cuántas instancias de una entidad pueden asociarse con instancias de otra. Debe responder a las reglas reales de la actividad.

• Uno a uno (1:1): un alumno tiene, como máximo, una credencial escolar vigente, y esa credencial está asignada a un solo alumno.

• Uno a muchos (1:N): un alumno puede realizar varios préstamos; cada préstamo corresponde a un alumno.

• Muchos a muchos (N:M): un alumno puede inscribirse en varios talleres; cada taller puede recibir a muchos alumnos.

También podemos indicar participación mínima: 0..N representa cero o muchos; 1..N representa uno o muchos. Por ejemplo, un alumno puede no tener préstamos todavía, pero todo préstamo registrado debe estar asociado a un alumno.

9. Octavo paso: construir el Modelo Entidad–Relación

Para nuestro laboratorio identificamos tres entidades: ALUMNO, EQUIPO y PRÉSTAMO. El modelo conceptual simplificado puede leerse de esta forma:

ALUMNO (1) — REALIZA — (N) PRÉSTAMO

EQUIPO (1) — PARTICIPA EN — (N) PRÉSTAMO

El modelo anterior significa que un alumno puede realizar varios préstamos a lo largo del tiempo y que un equipo puede aparecer en el historial de muchos préstamos distintos. En cambio, cada préstamo individual se relaciona con un único alumno y un único equipo.

La entidad PRÉSTAMO es importante porque almacena atributos propios del acontecimiento, como la fecha de salida y la fecha de devolución. Permite representar la asociación histórica entre alumnos y equipos sin perder información.

10. Noveno paso: transformar las entidades en tablas

Ahora pasamos del diseño conceptual al diseño lógico. En el Modelo Relacional, una entidad se transforma normalmente en una tabla y sus atributos se convierten en columnas.

Tabla ALUMNO: NumControl (PK), Nombre, Grupo.

Ejemplo de registros: 1001 | Luis Pérez | 4.º A; 1002 | Ana López | 4.º B.

Tabla EQUIPO: IdEquipo (PK), Tipo, Marca.

Ejemplo de registros: EQ001 | Laptop | Lenovo; EQ002 | Tablet | Huawei.

La tercera tabla será PRESTAMO, donde se conservarán todas las operaciones efectuadas.

11. Décimo paso: identificar claves foráneas

Una clave foránea o Foreign Key (FK) es una columna, o conjunto de columnas, cuyos valores hacen referencia a una clave candidata de otra tabla, generalmente a su clave primaria. Su función es conectar registros y ayudar a garantizar la integridad de los datos.

En la relación ALUMNO (1) — (N) PRESTAMO, NumControl es la PK de ALUMNO y una FK dentro de PRESTAMO. En EQUIPO (1) — (N) PRESTAMO, IdEquipo es la PK de EQUIPO y otra FK de PRESTAMO.

Tabla PRESTAMO: IdPrestamo (PK), NumControl (FK), IdEquipo (FK), FechaSalida, FechaDevolucion.

• Préstamo 501: alumno 1001, equipo EQ001, salida 01/10/2026, devolución 02/10/2026.

• Préstamo 502: alumno 1002, equipo EQ002, salida 03/10/2026, devolución 04/10/2026.

• Préstamo 503: alumno 1001, equipo EQ002, salida 06/10/2026, todavía sin devolución registrada.

En la base de datos real, FechaDevolucion puede ser NULL hasta que ocurra la devolución. Es mejor que escribir la palabra «pendiente» en una columna definida para fechas.

12. Undécimo paso: crear el diagrama relacional

El diagrama relacional muestra las tablas, sus columnas y las referencias entre claves. Puede expresarse con el siguiente esquema:

ALUMNO [ NumControl PK | Nombre | Grupo ]

EQUIPO [ IdEquipo PK | Tipo | Marca ]

PRESTAMO [ IdPrestamo PK | NumControl FK | IdEquipo FK | FechaSalida | FechaDevolucion ]

Relaciones: ALUMNO.NumControl (1) → (N) PRESTAMO.NumControl; EQUIPO.IdEquipo (1) → (N) PRESTAMO.IdEquipo.

Regla habitual: en una relación de uno a muchos (1:N), la clave foránea se coloca en la tabla del lado de muchos. En una relación muchos a muchos (N:M), generalmente se crea una tabla intermedia que contiene las referencias a ambas tablas y, si corresponde, los atributos de la asociación.

13. ¿Por qué no colocar todos los datos en una sola tabla?

Si escribimos el nombre del alumno, su grupo y la marca del equipo cada vez que registramos un préstamo, acumularemos información repetida. Si un estudiante cambia de grupo, habría que modificar varias filas y podríamos olvidar alguna.

Separar ALUMNO, EQUIPO y PRESTAMO reduce la redundancia innecesaria y facilita mantener la información consistente. Este razonamiento prepara el estudio de la normalización de bases de datos.

14. Duodécimo paso: verificar el diseño

Antes de implementar debemos comprobar que el modelo realmente resuelve el problema. ¿Podemos consultar los préstamos de un alumno? ¿Qué equipos no se han devuelto? ¿Cuántas veces se ha solicitado un equipo?

• Cada préstamo debe referirse a un alumno existente.

• Cada préstamo debe referirse a un equipo existente.

• Una fecha de devolución no debe ser anterior a la fecha de salida.

• Una unidad física no puede estar prestada a dos personas al mismo tiempo, salvo que la regla de negocio expresamente lo permita.

Las claves foráneas sirven para proteger las referencias entre tablas, pero algunas reglas, como impedir dos préstamos activos del mismo equipo, requieren validaciones adicionales.

15. Diferencias entre MER y Modelo Relacional

• Modelo Entidad–Relación: representa conceptualmente los elementos de la realidad, sus atributos, asociaciones y cardinalidades.

• Modelo Relacional: organiza lógicamente esos elementos en relaciones que solemos representar como tablas con columnas, claves primarias y claves foráneas.

• El MER corresponde al diseño conceptual; el esquema relacional corresponde al diseño lógico. Ninguno de los dos equivale todavía a la base de datos implementada.

Después de validar el diseño, las tablas podrán crearse en un sistema gestor como MySQL, MariaDB, PostgreSQL o Microsoft Access.

16. Práctica de aplicación: la papelería escolar

Una papelería necesita guardar productos, clientes y ventas. Cada producto tiene un código, un nombre y un precio. Cada cliente tiene identificador y nombre. Una venta puede contener varios productos y cada producto puede aparecer en diferentes ventas. Además, necesitamos conservar la cantidad vendida de cada producto.

• Identifica las entidades relevantes y proporciona instancias de ejemplo.

• Establece los atributos y selecciona sus claves primarias.

• Determina las relaciones y sus cardinalidades.

• Dibuja el MER utilizando rectángulos, rombos y óvalos.

• Convierte el MER en un esquema de tablas y señala las claves foráneas.

• Analiza si necesitas una tabla DETALLE_VENTA para registrar los productos y cantidades incluidos en cada venta.

Autoevaluación

• ¿Por qué primero debemos observar la realidad y delimitar el problema?

• ¿Cuál es la diferencia entre una entidad y una instancia?

• ¿Cómo se representa una relación uno a muchos?

• ¿Qué función tiene una clave foránea?

• ¿Por qué se utiliza una tabla intermedia en una asociación muchos a muchos?

17. Conclusión

El diseño de una base de datos inicia con la comprensión de la realidad y continúa con su abstracción. El MER permite identificar entidades, atributos, relaciones y cardinalidades. Al transformarlo en un Modelo Relacional obtenemos tablas y claves listas para orientar la implementación.

El objetivo no es acumular datos, sino organizarlos correctamente para evitar errores, facilitar consultas y resolver necesidades reales. La calidad de una base de datos depende en gran medida de la calidad de su diseño.

Lecturas anteriores del Módulo 4

1. Conceptos básicos de bases de datos — Repasa los fundamentos para reconocer datos, información, entidades y registros.

2. Modelo Entidad–Relación: guía práctica para diseñar una base de datos — Profundiza en la notación y construcción de relaciones.

Referencias bibliográficas

• Chen, P. P.-S. (1976). The entity-relationship model—Toward a unified view of data. ACM Transactions on Database Systems, 1(1), 9–36. https://doi.org/10.1145/320434.320440

• Codd, E. F. (1970). A relational model of data for large shared data banks. Communications of the ACM, 13(6), 377–387. https://doi.org/10.1145/362384.362685

• Elmasri, R., & Navathe, S. B. (2016). Fundamentals of database systems (7th ed.). Pearson.

• Silberschatz, A., Korth, H. F., & Sudarshan, S. (2019). Database system concepts (7th ed.). McGraw-Hill.