¿Qué es una entidad en una base de datos?

Imagina que estás construyendo una biblioteca digital. No puedes simplemente arrojar todos los libros, autores y préstamos en un mismo cajón digital. Necesitas una forma de organizar, clasificar y relacionar esa información para que sea útil. En el mundo del diseño de bases de datos, esa “forma de organizar” se llama entidad.

En esencia, una entidad es la representación de un objeto, persona, concepto o evento del mundo real sobre el cual necesitamos almacenar información. Entender este concepto es el primer bloque para construir sistemas de información robustos, y en esta guía, te lo explicaremos desde cero hasta un nivel avanzado de forma clara y práctica.

Más Allá de la Definición Simple: Desglosando el Concepto

Cuando empezamos a estudiar bases de datos, a menudo nos quedamos con la idea de que una entidad es simplemente una «tabla». Si bien esta es una forma práctica de visualizarla en un modelo relacional, el concepto es mucho más profundo y fundamental. Una entidad es una abstracción. No es la tabla en sí, sino la idea de lo que esa tabla representa.

Piénsalo de esta manera: en un sistema de gestión académica, «Estudiante» es una entidad. No es Juan Pérez ni María García; es el concepto genérico que agrupa a todos ellos. Cada estudiante individual (Juan, María) es una ocurrencia o instancia de esa entidad. La entidad «Estudiante» nos permite definir, de una sola vez, qué tipo de información (atributos) nos interesa guardar de todos los estudiantes.

Los Tres Pilares de una Entidad

Para comprender verdaderamente qué es una entidad, debes conocer sus tres componentes esenciales:

1. Nombre de la Entidad: Es un sustantivo singular que describe de manera única el concepto. Debe ser claro, conciso y representativo del negocio. Ejemplos: Cliente, Producto, Factura, Vuelo. Las buenas prácticas dictan usar PascalCase o snake_case: Cliente o cliente, ProductoVendido o producto_vendido.
2. Atributos: Son las propiedades o características que describen a la entidad. En el mundo real, los atributos serán las columnas de tu tabla. Si la entidad es Libro, sus atributos podrían ser ISBN, titulo, anio_publicacion y precio. Cada atributo almacena una pieza específica de dato.
3. Instancia (o Tupla): Es cada una de las filas o registros concretos dentro de la entidad. Representa una ocurrencia única e identificable. Por ejemplo, una instancia de la entidad Libro sería: (978-3-16-148410-0, "Cien Años de Soledad", 1967, 25.90).

Tipos de Entidades: ¿Todas son Iguales?

No, en absoluto. Clasificar las entidades es crucial para un buen diseño. Principalmente, encontramos dos grandes categorías:

1. Entidades Fuertes (o Regulares)

Son las entidades autónomas, las que no dependen de ninguna otra para existir en el modelo. Tienen su propia clave primaria (un identificador único) que las define por completo. Son los actores principales de tu sistema.

• Ejemplos Clave:
  • En un hospital: Paciente, Médico, Medicamento.
  • En un e-commerce: Cliente, Producto, Categoría.
  • En una universidad: Asignatura, Aula, Profesor.

2. Entidades Débiles

Son aquellas que no pueden existir por sí mismas en la base de datos. Su existencia depende de la existencia de una entidad fuerte. No tienen una clave primaria propia y completa; necesitan «heredar» o combinar su clave con la de la entidad fuerte de la que dependen.

• Ejemplo Didáctico: Piensa en la entidad Empleado y la entidad Dependiente (hijos, cónyuges). Un dependiente no existe en el sistema de recursos humanos si no está asociado a un empleado activo. Si el empleado se va, su registro de dependientes también se elimina. La clave primaria de Dependiente podría ser una combinación de ID_Empleado (clave foránea) y un campo como Numero_Secuencial.
• Otro ejemplo clásico es Habitación en un Hotel. Una habitación (ej: la número 312) no tiene sentido sin el hotel al que pertenece.

Las Reglas del Juego: Cómo Identificar una Buena Entidad

Un error común de principiante es convertir cualquier dato en una entidad. Para evitarlo, hazte estas tres preguntas de validación:

1. ¿Tiene más de un atributo? Si lo único que necesitas guardar es un valor único y sin más descripción (por ejemplo, el color de un coche en un sistema simple), probablemente sea un atributo de otra entidad, no una entidad en sí misma.
2. ¿Existen múltiples instancias? ¿Vas a tener más de un registro de esto? Un sistema puede tener una sola configuración general. En ese caso, no se modela como una entidad, sino como una tabla de parámetros o un archivo de configuración.
3. ¿Es un concepto fundamental y autónomo en tu modelo de negocio? «Precio» no es una entidad, es un atributo. «Matrícula» no es una entidad, es el acto de matricularse, que se puede modelar mejor como una relación entre Alumno y Curso, o como una entidad si tiene atributos propios como fecha_matricula y nota_final.

Entidades en el Modelo Relacional: El Mapa Hacia las Tablas

Hasta ahora hemos hablado de forma conceptual. El siguiente paso es cómo esto se traduce en tu gestor de bases de datos (MySQL, PostgreSQL, SQL Server).

Una entidad se transforma directamente en una tabla.
Los atributos se convierten en columnas (o campos).
Cada instancia se convierte en una fila (o registro).

Pero aquí emerge un concepto crítico: la Clave Primaria (Primary Key – PK). Es el mecanismo que garantiza que cada fila en tu tabla sea única e inequívocamente identificable. Sin una PK, tu entidad es una simple lista de datos sin integridad. Los tipos de claves más comunes son:

• Clave Natural: Utiliza un atributo que ya existe en el mundo real y es único. Ejemplo: el ISBN para un libro o el DNI/NIE para una persona. A primera vista parecen perfectas, pero tienen riesgos: ¿qué pasa si una persona no tiene DNI o si la regla de negocio cambia y se permiten duplicados?
• Clave Surrogada (o Artificial): Es la opción más recomendada y robusta. Creas un campo numérico autoincremental (id_libro, id_paciente) que no tiene ningún significado en el mundo real. Es simple, eficiente y nunca cambiará, lo que la hace ideal para relacionar tablas.

De la Teoría a la Práctica: Un Caso de Estudio Completo

Diseñemos juntos la base de datos para una biblioteca universitaria. Analicemos el mundo real para extraer entidades.

Entidad Fuerte: Libro

• id_libro (PK, Entero, Autoincremental)
• isbn (VARCHAR, Único)
• titulo (VARCHAR, No nulo)
• anio_publicacion (INT)
• editorial (VARCHAR)
• numero_paginas (SMALLINT)

Entidad Fuerte: Autor

• id_autor (PK, Entero, Autoincremental)
• nombre (VARCHAR, No nulo)
• apellidos (VARCHAR, No nulo)
• nacionalidad (VARCHAR)

Entidad Fuerte: Estudiante

• id_estudiante (PK, Entero, Autoincremental)
• numero_matricula (VARCHAR, Único)
• nombre_completo (VARCHAR)
• email_institucional (VARCHAR, Único)

Entidad Débil: Ejemplar

• id_ejemplar (PK, Entero, Autoincremental, o PK compuesta)
• id_libro (PK, FK hacia Libro)
• codigo_barras (VARCHAR, Único)
• estado (ENUM: ‘Disponible’, ‘Prestado’, ‘En reparación’)
• ubicacion_estanteria (VARCHAR)

Entidad Asociativa (para relación Muchos a Muchos): Prestamo

• id_prestamo (PK, Entero, Autoincremental)
• id_ejemplar (FK hacia Ejemplar)
• id_estudiante (FK hacia Estudiante)
• fecha_prestamo (DATE, No nulo)
• fecha_devolucion_prevista (DATE)
• fecha_devolucion_real (DATE)

Análisis del Diseño del Caso

Observa cómo no todo es una entidad fuerte:

• Ejemplar representa un libro físico específico. No es lo mismo el concepto Libro (título, autor) que una copia física con su propio código de barras y ubicación. Depende de Libro para su significado completo.
• La relación «Un libro es escrito por varios autores y un autor escribe varios libros» es una relación de Muchos a Muchos (N:M). En el modelo físico, esta relación se resuelve creando una tabla intermedia o entidad asociativa, que podríamos llamar Libro_Autor, con campos id_libro, id_autor y quizás orden_del_autor como atributo.

Entidad vs. Relación vs. Atributo: Aclarando Conceptos con Ejemplos

Esta es la confusión más frecuente. Usemos el enunciado: «El cliente Juan García realizó un pedido el 5 de octubre con un importe de 150€».

1. ¿Cuál es la entidad? Los sustantivos clave. Aquí son Cliente y Pedido. Representan los objetos principales.
2. ¿Cuál es la relación? El verbo que los conecta. «Realizó» define la relación entre las entidades. La frase «Un cliente realiza uno o muchos pedidos» es una relación 1:N.
3. ¿Cuáles son los atributos? Las características de los sustantivos. Para Cliente: su nombre («Juan García»). Para Pedido: su fecha («5 de octubre») y su importe («150€»).

Entender esta distinción gramatical es una técnica simple pero poderosísima al relevar los requisitos de una base de datos con un usuario o un cliente.

Errores Frecuentes al Modelar Entidades (y Cómo Evitarlos)

Incluso estudiantes avanzados caen en estas trampas. Conocerlas te dará una ventaja:

• El «atributo-monstruo»: Meter en un solo campo direccion la calle, el número, la ciudad y el código postal. Solución: Descomponer en atributos atómicos: calle, numero, ciudad, codigo_postal. Esto permite consultar fácilmente «todas las personas de la ciudad de Madrid».
• Campos calculados innecesarios: Crear un atributo edad que se inserta manualmente. Solución: Solo almacena fecha_nacimiento. La edad se calcula en una consulta SELECT en tiempo real. Almacenar datos calculables es una fuente de errores e inconsistencia.
• Violación de la integridad de entidad: Ocurre cuando permites que la clave primaria de una tabla sea NULA. Esto es gravísimo, ya que una PK nula no puede identificar una instancia. Un buen diseño siempre define todas las columnas de la PK como NOT NULL.

La Evolución del Concepto: ¿Solo Existen en BD Relacionales?

Aunque el término «entidad» es central en el modelo relacional (SQL), el concepto abstracto persiste en otros paradigmas.

• Bases de Datos NoSQL (Documentales como MongoDB): Una entidad deja de ser una tabla y se convierte en una colección de documentos JSON. El documento en sí agrupa los atributos, a menudo de forma anidada, rompiendo la idea de entidades débiles. Un documento cliente puede contener un array con todos los documentos de sus direcciones dentro.
• Bases de Datos Orientadas a Grafos (Neo4j): La entidad se convierte en un nodo. Los atributos son las propiedades del nodo. Las relaciones entre entidades son conexiones de primera clase, no simples claves foráneas.

Entender la base conceptual de qué es una entidad te facilita migrar tu lógica de diseño entre distintas tecnologías.

Resultados de Aprendizaje

Al finalizar la lectura completa de este artículo, deberías ser capaz de:

1. Definir con precisión qué es una entidad, distinguiéndola de una simple tabla y comprendiendo su rol como abstracción del mundo real en el diseño de bases de datos.
2. Identificar y desglosar los tres componentes fundamentales de una entidad (nombre, atributos e instancias) en cualquier ejemplo práctico.
3. Clasificar críticamente una entidad como fuerte o débil, justificando su dependencia existencial y proponiendo su clave primaria adecuada.
4. Aplicar reglas de validación para decidir si un concepto del negocio debe ser modelado como una entidad, un atributo o una relación, evitando errores comunes de diseño.
5. Resolver un modelo entidad-relación práctico, como el de una biblioteca, y traducirlo correctamente a una estructura de tablas con claves primarias y foráneas.
6. Diferenciar con claridad una entidad de una relación y un atributo, utilizando la técnica de análisis gramatical de los requerimientos de un sistema.

Rodrigo Ricardo Editor y fundador