Bases de datos
Entidades y atributos
Qué es una entidad y qué la distingue de un atributo, cómo se nombran, qué tipos de atributo existen y los errores clásicos al elegirlos.
Entidad: una cosa de la que guardo varios datos
Una entidad es un tipo de cosa sobre la que el sistema necesita guardar información: ALUMNO, CURSO, PROFESOR, FACTURA, MASCOTA. No es una cosa concreta, sino la categoría.
Esa distinción tiene nombre:
| Término | Qué es | Ejemplo |
|---|---|---|
| Entidad | El tipo, la categoría | ALUMNO |
| Instancia | Un caso concreto de esa entidad | “Ana Ruiz, ana@mail.com” |
Una entidad tiene que cumplir tres condiciones. Si alguna falla, probablemente no sea una entidad:
- Es significativa para el negocio. Alguien la nombraría al describir cómo funciona el sistema.
- Se guarda más de un dato de ella. Si solo guardas su nombre y nada más, es candidata a ser un atributo de otra cosa.
- Puede haber muchas instancias. ALUMNO tiene sentido porque hay muchos alumnos; “el instituto”, del que hay uno solo, casi nunca es una entidad.
La entidad se nombra en singular y en mayúsculas: ALUMNO, no “Alumnos”. El nombre describe qué es cada instancia. Es una convención, pero es la que usa Data Modeler y toda la bibliografía de Oracle, y respetarla evita ambigüedades al leer un diagrama ajeno.
Cómo se dibuja
En la notación Barker —la que usa Data Modeler por defecto para el modelo lógico— una entidad es una caja de esquinas redondeadas con el nombre arriba y los atributos listados adentro:
┌──────────────────────────┐
│ ALUMNO │
├──────────────────────────┤
│ # id_alumno │
│ * nombre │
│ * email │
│ o telefono │
└──────────────────────────┘Los símbolos #, * y o delante de cada atributo son el tema de la página siguiente. Por ahora, lo que importa es la estructura: nombre arriba, atributos abajo, uno por línea.
Atributo: un dato de esa cosa
Un atributo describe una propiedad de la entidad. Es un valor único por instancia: cada alumno tiene un nombre, un email.
┌──────────────────────────┐ Instancias:
│ CURSO │ ("JAV-01", "Java Básico", 40)
├──────────────────────────┤ ("BD-01", "Bases de Datos", 30)
│ # codigo │ ("WEB-02", "HTML y CSS", 24)
│ * nombre │
│ * horas │
│ o descripcion │
└──────────────────────────┘Convenciones de nombre para atributos:
| Regla | Bien | Mal |
|---|---|---|
| En minúsculas, singular | nombre, fecha_inicio | NOMBRES |
| Sin repetir el nombre de la entidad | ALUMNO → nombre | ALUMNO → nombre_alumno |
| Describiendo el dato, no su tipo | fecha_inicio | campo_fecha_1 |
| Sin espacios ni acentos | telefono | teléfono de contacto |
La segunda regla tiene una excepción muy extendida: el identificador. id_alumno dentro de ALUMNO repite el nombre de la entidad a propósito, porque ese atributo va a viajar a otras tablas como clave foránea y ahí id a secas sería ambiguo. Es la convención más común, y la que se usa en toda esta sección.
¿Entidad o atributo? El error más frecuente
La duda que aparece siempre: si un curso tiene un profesor, ¿profesor es un atributo de CURSO o una entidad aparte?
La pregunta que lo decide: ¿guardo más de un dato de eso?
Si de un profesor solo guardo su nombre:
┌──────────────────────────┐
│ CURSO │
│ * nombre │
│ * profesor ← atributo, alcanza
└──────────────────────────┘
Si de un profesor guardo nombre, email y teléfono:
┌────────────────┐ ┌──────────────────┐
│ CURSO │ │ PROFESOR │
│ * nombre │──────────│ * nombre │
└────────────────┘ │ * email │
│ o telefono │
└──────────────────┘Tres señales de que algo que pusiste como atributo debería ser una entidad:
| Señal | Ejemplo |
|---|---|
| El valor se repite idéntico en muchas instancias | El mismo nombre de profesor escrito en 20 cursos |
| Querrías guardar datos sobre ese valor | El email de ese profesor |
| Existe aunque no haya ninguna instancia de la otra | Un profesor contratado que todavía no dicta nada |
Y una señal en el otro sentido: si al crear una entidad te queda con un solo atributo y no participa de ninguna relación interesante, probablemente era un atributo.
Este mismo criterio decide una duda muy parecida: un atributo pais con el nombre del país escrito a mano se repite miles de veces, se escribe mal (“Argentina”, “argentina”, “Argnetina”) y no se puede validar. Convertirlo en la entidad PAÍS y relacionarlo garantiza que solo existan los países que alguien cargó, escritos de una única manera.
Tipos de atributo que conviene reconocer
Atributo compuesto
Un dato que en realidad son varios juntos:
* direccion → * calle
* numero
* ciudad
o pisoGuardarlo entero como "Av. Siempre Viva 742, Springfield" hace imposible buscar por ciudad sin trucos de texto. Descomponer un atributo compuesto en sus partes es casi siempre lo correcto, salvo que el sistema jamás vaya a necesitar las partes por separado.
Atributo multivaluado
Un dato del que una instancia puede tener varios valores:
* telefono → ¿y si el alumno tiene dos?La tentación es poner telefono_1, telefono_2, telefono_3. Es un mal arreglo: si aparece un cuarto teléfono hay que cambiar la estructura, y los que sobran quedan vacíos ocupando lugar.
La solución correcta es una entidad aparte, relacionada con la original:
┌────────────────┐ ┌──────────────────┐
│ ALUMNO │ │ TELEFONO │
│ * nombre │─────────<│ * numero │
│ * email │ │ * tipo │
└────────────────┘ └──────────────────┘Ahora un alumno puede tener cero, uno o cien teléfonos sin tocar el modelo.
Esta es la regla que más se viola en bases de datos reales, y siempre con el mismo síntoma: columnas numeradas (tel1, tel2) o una columna de texto con valores separados por comas. Las dos formas hacen que buscar “quién tiene este teléfono” sea incómodo, lento y propenso a errores.
Atributo derivado
Un dato que se puede calcular a partir de otros:
| Derivado | Se calcula desde |
|---|---|
edad | fecha_nacimiento y la fecha de hoy |
total de una factura | La suma de sus líneas |
cantidad_alumnos de un curso | Contar las inscripciones |
Como regla, no se guardan: se calculan al consultarlos. Guardar edad obliga a actualizarla cada cumpleaños, y el día que alguien se olvide, la base miente. Guardar fecha_nacimiento es un dato que no cambia nunca.
La excepción es el rendimiento: en un sistema con millones de facturas, recalcular el total en cada consulta puede ser caro, y entonces se guarda a propósito. Pero eso es una decisión del modelo físico, tomada con un problema medido delante, no algo que se decida mientras se dibuja el modelo lógico.
El ejemplo del instituto, primer borrador
Volviendo al enunciado del instituto, los sustantivos con varios datos asociados dan estas tres entidades:
┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐
│ ALUMNO │ │ CURSO │ │ PROFESOR │
├──────────────────┤ ├──────────────────┤ ├──────────────────┤
│ nombre │ │ codigo │ │ nombre │
│ email │ │ nombre │ │ email │
│ telefono │ │ horas │ │ telefono │
└──────────────────┘ └──────────────────┘ └──────────────────┘Falta bastante: cuáles son obligatorios, cuál identifica a cada instancia, y cómo se conectan entre sí. Y falta una entidad que el enunciado esconde — la inscripción, con su fecha y su nota — que va a aparecer cuando lleguemos a las relaciones muchos a muchos.
Pon a prueba
Una biblioteca te dice: “De cada libro guardamos título, ISBN y año. Cada libro pertenece a una categoría, y de cada categoría guardamos su nombre, una descripción y quién es el responsable de esa sección.”
¿Cómo se modela la categoría?
Esta entidad tiene cuatro problemas de diseño de atributos. Encuéntralos y propón la corrección.
┌────────────────────────────────┐
│ EMPLEADOS │
├────────────────────────────────┤
│ nombre_empleado │
│ direccion_completa │
│ telefono1 │
│ telefono2 │
│ fecha_nacimiento │
│ edad │
└────────────────────────────────┘1. EMPLEADOS está en plural. La entidad describe qué es cada instancia: debe llamarse EMPLEADO.
2. nombre_empleado repite el nombre de la entidad. Dentro de EMPLEADO, nombre ya es inequívoco. La redundancia solo hace más largo cada nombre sin agregar información.
3. direccion_completa es un atributo compuesto y telefono1/telefono2 uno multivaluado disfrazado. La dirección se descompone en calle, numero, ciudad, codigo_postal. Los teléfonos se sacan a una entidad TELEFONO relacionada, para que un empleado pueda tener los que haga falta sin cambiar la estructura.
4. edad es un atributo derivado. Se calcula desde fecha_nacimiento, así que guardarla obliga a actualizarla cada año y garantiza que tarde o temprano quede desactualizada. Se elimina.
Corregido:
┌────────────────────────┐ ┌──────────────────┐
│ EMPLEADO │ │ TELEFONO │
├────────────────────────┤ ├──────────────────┤
│ nombre │───────<│ numero │
│ calle │ │ tipo │
│ numero │ └──────────────────┘
│ ciudad │
│ codigo_postal │
│ fecha_nacimiento │
└────────────────────────┘Ordena los pasos del método para pasar de un enunciado en palabras a un primer borrador de entidades y atributos.
- Listar debajo de cada entidad los datos que se guardan de ella
- Subrayar los sustantivos: son los candidatos a entidad
- Nombrar cada entidad en singular y mayúsculas
- Eliminar los atributos derivados que se pueden calcular
- Sacar a una entidad aparte los atributos multivaluados
- Descomponer los atributos compuestos en sus partes
- Descartar los que solo aportan un dato: esos son atributos
- Leer el enunciado completo sin escribir nada todavía
Siguiente paso
Las cajas ya tienen sus atributos, pero todos parecen igual de importantes. Falta marcar cuáles son obligatorios, cuáles opcionales y cuál identifica a cada instancia sin lugar a dudas — eso es lo que hacen los símbolos #, * y o — ver Los símbolos: #, * y o.