Todos los cursos > Informática ( TI ) > Banco de datos ::

Entidades y Atributos en el Modelado de Datos

Capítulo 2

Tiempo estimado de lectura: 9 minutos

Cómo descubrir entidades a partir de un escenario de negocio

En modelado de datos, una entidad representa un “tipo de cosa” del negocio sobre la que necesitamos almacenar información de forma consistente (por ejemplo: Cliente, Producto, Sucursal). La clave práctica es identificar elementos que tienen identidad y persisten más allá de una acción puntual.

Checklist rápido: ¿esto es una entidad?

Se puede contar (hay muchos): “clientes”, “productos”, “pedidos”.
Tiene ciclo de vida: se crea, se actualiza, puede desactivarse.
Se identifica: existe una forma de distinguir una instancia de otra.
Guarda atributos propios: nombre, fecha, estado, etc.
Se relaciona con otras cosas: un Pedido pertenece a un Cliente.

Distinguir entidades de procesos y documentos

Un error común es confundir procesos (acciones) o documentos (formatos) con entidades. La diferencia se aclara preguntando: “¿Necesito almacenar esto como un objeto del negocio o solo describe una actividad/soporte?”

Elemento del escenario	Suele ser	Señales	Ejemplo de modelado
“Registrar una venta”, “Aprobar un crédito”	Proceso	Verbo + objeto; describe una acción	La entidad suele ser Venta o SolicitudCrédito, no “Registrar”/“Aprobar”
“Factura PDF”, “Formulario”, “Ticket impreso”	Documento	Es un medio/representación	La entidad es Factura; el PDF puede ser un atributo (ruta/URL) o entidad si hay gestión documental
“Pedido”, “Cliente”, “Producto”	Entidad	Sustantivo; tiene identidad y datos propios	Tablas/entidades con atributos y relaciones

Guía paso a paso para extraer entidades

Subraya sustantivos del texto del negocio (candidatos a entidad o atributo).
Marca verbos (candidatos a procesos). Pregunta: “¿el resultado del proceso es una entidad persistente?”
Detecta listas (“un pedido tiene ítems”, “un cliente tiene teléfonos”): suelen indicar entidades hijas o atributos multivaluados.
Continúa en nuestra aplicación.
- Escuche el audio con la pantalla apagada.
- Obtenga un certificado al finalizar.
- ¡Más de 5000 cursos para que explores!
O continúa leyendo más abajo...
Descargar la aplicación
Busca identificadores mencionados (número de pedido, DNI, SKU). Si no existen, anota el riesgo y considera identificadores sustitutos.
Valida con preguntas de negocio: “¿Se consulta esto?”, “¿Se audita?”, “¿Se necesita historial?” Si sí, tiende a entidad.

Definición de atributos: significado, dominio, formato y obligatoriedad

Un atributo es una propiedad de una entidad. Definir atributos no es solo “poner columnas”: implica capturar el significado de negocio y las reglas que lo hacen consistente.

Plantilla de especificación de un atributo

Campo	Qué documentar	Ejemplo
Nombre	Nombre claro y estable	`email`
Significado de negocio	Qué representa y para qué se usa	Correo principal para notificaciones y acceso
Dominio	Conjunto de valores válidos	Formato email; longitud máx. 254
Formato / tipo	Tipo lógico y físico	`VARCHAR(254)`
Obligatoriedad	Si puede ser nulo y en qué casos	Obligatorio si el cliente acepta comunicaciones
Reglas	Validaciones y unicidad	Único por cliente; normalizado a minúsculas
Ejemplos	Valores de muestra	`ana.perez@empresa.com`

Dominios: más allá del tipo de dato

El dominio define valores permitidos desde el negocio. Dos atributos pueden ser VARCHAR pero tener dominios distintos (por ejemplo, codigo_postal vs sku). Cuando el dominio es cerrado o controlado, conviene explicitarlo:

Enumeraciones: estado_pedido ∈ {CREADO, PAGADO, ENVIADO, CANCELADO}.
Rangos: porcentaje_descuento entre 0 y 100.
Patrones: codigo con regex o máscara (p. ej., AAA-9999).
Referencias: pais basado en catálogo (ISO 3166) como entidad/tabla de referencia.

Obligatoriedad: cuándo un atributo es realmente requerido

“Obligatorio” rara vez es absoluto; suele depender del estado o del canal. Documenta la regla condicional:

Obligatorio siempre: fecha_creacion.
Obligatorio por evento: fecha_envio solo si el pedido está ENVIADO.
Obligatorio por tipo: nro_documento si el cliente es “persona física”.

En el modelo lógico, estas reglas se registran como restricciones (y luego se implementan con NOT NULL, CHECK, validaciones en aplicación o triggers según el caso).

Identificadores: naturales vs. sustitutos (surrogate)

Un identificador distingue de forma única cada instancia de una entidad. Elegirlo bien impacta integridad, integraciones y mantenimiento.

Reglas prácticas para elegir identificadores naturales

El valor ya existe en el negocio y se usa para referenciar.
Es estable (no cambia o cambia muy raramente).
Es único con una regla clara.
No es excesivamente largo ni sensible.

Ejemplos típicos: SKU (si es gobernado), numero_cuenta (si es estable), codigo_sucursal.

Cuándo preferir identificadores sustitutos

El identificador natural puede cambiar (correo electrónico, teléfono).
La unicidad depende de condiciones complejas o temporales.
El identificador natural es compuesto y voluminoso (varios campos).
Hay integración con múltiples sistemas con reglas distintas.

Ejemplo: usar cliente_id (surrogate) y mantener nro_documento como clave candidata con restricción de unicidad cuando aplique.

Cómo documentar claves candidatas

Una clave candidata es cualquier conjunto mínimo de atributos que identifica de forma única. Documentarlas evita perder reglas del negocio cuando se introduce un surrogate.

Entidad	Clave primaria (PK)	Claves candidatas (UK)	Notas
Cliente	`cliente_id`	`(tipo_doc, nro_doc)`, `(email)` (si aplica)	`email` puede no existir; `nro_doc` puede repetirse si cambia el tipo_doc
Producto	`producto_id`	`(sku)`	SKU gobernado por catálogo corporativo
Pedido	`pedido_id`	`(nro_pedido)`	`nro_pedido` visible al cliente; puede reiniciarse por sucursal → entonces sería `(sucursal, nro_pedido)`

Atributos compuestos, multivaluados y derivados

Atributos compuestos

Un atributo compuesto se puede descomponer en partes con significado propio.

Ejemplo: direccion → calle, número, piso, ciudad, código_postal, país.
Regla: si vas a buscar/filtrar/validar por partes (código postal, ciudad), modela las partes como atributos separados.

En un modelo lógico relacional, suele ser mejor almacenar las partes atómicas. Puedes mantener un campo “formateado” solo si es necesario como derivado o para presentación.

Atributos multivaluados

Un atributo multivaluado admite múltiples valores para una misma entidad.

Ejemplo: un Cliente tiene varios teléfonos.
Regla: en relacional, un multivaluado casi siempre se transforma en una entidad relacionada (tabla hija).

Cliente(cliente_id, nombre, ...)

TelefonoCliente(telefono_id, cliente_id, tipo, numero, es_principal)

La presencia de metadatos del valor (tipo, principal, fecha_alta) refuerza que debe ser entidad.

Atributos derivados

Un atributo derivado se calcula a partir de otros.

Ejemplo: edad derivada de fecha_nacimiento.
Ejemplo: total_pedido derivado de la suma de ítems.

Regla: si el valor puede recalcularse de forma confiable, evita almacenarlo para no introducir inconsistencias. Se almacena cuando hay razones claras: performance, auditoría, “congelar” el valor en el tiempo (por ejemplo, total facturado en una factura emitida).

Cuándo un atributo debe transformarse en entidad

Multivaluado (lista de valores).
Requiere atributos propios (por ejemplo, “dirección” con tipo, vigencia, geolocalización).
Tiene relaciones con otras entidades (por ejemplo, “método de pago” asociado a transacciones).
Necesita historial (cambios a lo largo del tiempo).
Se reutiliza por varias entidades (catálogos: País, Moneda, Estado).

Ejercicios guiados: extraer entidades y atributos (con supuestos)

En cada ejercicio: (1) lista entidades, (2) lista atributos por entidad con dominio/obligatoriedad, (3) define identificadores y claves candidatas, (4) registra supuestos.

Ejercicio 1

Descripción: “Una clínica registra pacientes. De cada paciente se guarda nombre, fecha de nacimiento y uno o más teléfonos. Cada turno se agenda para un paciente con fecha y hora, y un estado (reservado, confirmado, cancelado).”

Paso 1: entidades candidatas

Paciente (persistente, se consulta).
Turno (evento persistente con estado).
Teléfono (multivaluado y con posible tipo/principal).

Paso 2: atributos propuestos

Paciente: paciente_id (PK surrogate), nombre (obligatorio), fecha_nacimiento (obligatorio, dominio fecha pasada).
TelefonoPaciente: telefono_id (PK), paciente_id (FK), numero (obligatorio, patrón E.164 o regla local), tipo (opcional: móvil/fijo), es_principal (opcional, boolean).
Turno: turno_id (PK), paciente_id (FK), fecha_hora (obligatorio), estado (obligatorio, dominio {RESERVADO, CONFIRMADO, CANCELADO}).

Paso 3: identificadores y claves candidatas

Paciente: si no hay DNI u otro identificador, usar surrogate. Clave candidata potencial: (nombre, fecha_nacimiento) no recomendable por colisiones.
Turno: clave candidata posible (paciente_id, fecha_hora) si la clínica no permite dos turnos al mismo tiempo para el mismo paciente.

Paso 4: supuestos

Un paciente puede tener múltiples teléfonos y uno puede marcarse como principal.
El estado del turno es un conjunto cerrado.

Ejercicio 2

Descripción: “Una tienda online gestiona productos con SKU, nombre y precio vigente. Los clientes realizan pedidos. Un pedido tiene varios ítems, cada ítem indica producto, cantidad y precio unitario al momento de la compra.”

Entidades

Producto (tiene SKU, se consulta).
Cliente (no se detallan atributos; se asume al menos identificación).
Pedido (cabecera).
ItemPedido (detalle multivaluado con atributos propios).

Atributos clave y reglas

Producto: producto_id (PK), sku (UK, dominio alfanumérico), nombre (obligatorio), precio_vigente (obligatorio, decimal >= 0).
Pedido: pedido_id (PK), cliente_id (FK), fecha_creacion (obligatorio), estado (dominio controlado).
ItemPedido: item_id (PK) o PK compuesta (pedido_id, nro_linea); producto_id (FK), cantidad (obligatorio, entero > 0), precio_unitario (obligatorio, “congelado” al comprar).

Decisiones justificadas

precio_unitario en ItemPedido es un atributo que se almacena (derivado del precio vigente, pero debe quedar histórico).
Los ítems son una entidad porque el pedido “tiene varios” y cada uno tiene cantidad y precio.

Supuestos

El SKU es único y estable (si no lo fuera, se mantiene como atributo no único y se usa surrogate + otra regla).

Ejercicio 3

Descripción: “Una empresa registra empleados. Cada empleado tiene nombre completo, correo corporativo y una dirección. La dirección incluye calle, número, ciudad y país. Un empleado puede tener más de una dirección (por ejemplo, fiscal y envío).”

Entidades y transformación de atributos

Empleado como entidad principal.
Dirección no debe quedar como un solo atributo: es compuesto y además multivaluado (más de una por empleado) → se transforma en entidad DireccionEmpleado.
País puede ser atributo simple (texto) o entidad de referencia si se requiere catálogo y consistencia.

Atributos propuestos

Empleado: empleado_id (PK), nombre_completo (obligatorio), email_corporativo (obligatorio, UK, dominio email corporativo).
DireccionEmpleado: direccion_id (PK), empleado_id (FK), tipo (dominio {FISCAL, ENVIO, OTRO}), calle, numero, ciudad, pais (todos obligatorios salvo reglas locales).

Supuestos

Un empleado no comparte direcciones con otros empleados (si las compartiera, Dirección podría ser entidad independiente reutilizable).

Registro de supuestos y decisiones (formato recomendado)

Para que el modelo sea defendible, registra decisiones y supuestos junto al análisis. Un formato simple:

Elemento	Decisión	Justificación	Supuesto/Riesgo
Teléfonos de cliente	Entidad hija `TelefonoCliente`	Multivaluado; puede tener tipo y principal	Se asume que un cliente puede tener N teléfonos
Email como identificador	No usar como PK; sí como UK opcional	Puede cambiar; no siempre existe	Definir política de unicidad por tenant/país si aplica
Total de pedido	Derivado (no almacenar) o almacenar con regla	Evitar inconsistencias; almacenar si se “congela”	Si se almacena, definir cuándo se recalcula

Mini-guía de verificación antes de cerrar entidades y atributos

¿Cada entidad tiene un identificador definido (PK) y claves candidatas documentadas?
¿Cada atributo tiene significado de negocio, dominio y obligatoriedad (incluyendo condiciones)?
¿Los atributos multivaluados se transformaron en entidades hijas?
¿Los compuestos se descompusieron cuando se necesitan búsquedas/validaciones por partes?
¿Los derivados se almacenan solo si hay una razón explícita (histórico, auditoría, performance)?
¿Quedaron supuestos registrados para validar con el negocio?

Ahora responde el ejercicio sobre el contenido:

Al modelar datos, ¿en qué situación es más adecuado transformar un atributo en una entidad relacionada en lugar de dejarlo como una sola columna?

¡Tienes razón! Felicitaciones, ahora pasa a la página siguiente.

¡Tú error! Inténtalo de nuevo.

Un atributo debe pasar a entidad cuando puede tener múltiples valores por instancia o cuando el “valor” requiere atributos propios, historial o relaciones. En modelos relacionales, esto suele resolverse con una tabla hija vinculada por una clave foránea.