Modelo entidad-relacin, un ejemplo prctico

I. Matriculacin
En el desarrollo de software para empresas, el almacenamiento de la informacin de un modo
organizado es fundamental la mayora de los casos en los que el programador contesta no
se puede hacer a un requerimiento de un cliente se debe a un error en el modelado de la
base de datos que funciona como soporte a la aplicacin.

Como, de alguna forma, estamos especializados en el software de gestin de empresas de

enseanza, voy a utilizar un ejemplo de uno de esos modelos: la gestin de matriculacin de
los alumnos, incluyendo los recibos que tienen que pagar, y el pago parcial de los mismos.

Se explicar el funcionamiento del proceso (para que podamos hacer el seguimiento de la

implementacin), las tablas que utilizamos y los campos (de forma resumida) que componen
cada una de las tablas. Se dar una idea de los ndices, procedimientos almacenados y
triggers que nos pueden resultar tiles para que el rendimiento de la base de datos sea bueno.

Descripcin del proceso de matriculacin (el caso de uso)

Vamos a imaginarnos que nos encontramos en una academia de idiomas, en la que los
alumnos se matriculan y asisten a clase de forma temporal. En este caso me voy a centrar en
lo que se llaman grupos abiertos, es decir, grupos en los que cualquiera se puede matricular
(en oposicin a los grupos de empresa o grupos cerrados, que suelen funcionar de forma
diferente).

Cuando llegamos a la academia, se nos ofrece un folleto o catlogo de productos y servicios,

en el que se detallan los diferentes cursos en los que nos podemos matricular, y las diferentes
formas de pago que podemos utilizar. Seleccionamos uno de los cursos, la forma de pago que
ms nos conviene, el horario al que vamos a asistir, y con esta informacin nos matriculamos.

Como forma de pago, en este caso, vamos a utilizar un pago mensual, y queremos que se nos
domicilie el pago a travs de nuestra cuenta bancaria.

En la academia, llegado este punto, introducen en su sistema de informacin nuestros datos y

nos imprimen el contrato de prestacin de servicios, en el que se incluyen todos nuestros
datos, el curso en el que nos hemos matriculado y todos los pagos que vamos a tener que
realizar mientras estemos matriculados. Nos piden, de paso, que paguemos una reserva de
plaza, que es una pequea cantidad del primer recibo.

En el siguiente da de clase, nos presentamos, y el profesor comprueba en su hoja de

asistencia que estamos incluidos en el grupo nos da la bienvenida, y empezamos a estudiar.

El modelo de datos
A partir de aqu har una descripcin de la estructura de tablas y columnas para almacenar la
informacin de este proceso. Primero, algunas generalidades sobre cmo crear los campos.

Generalidades
Hay algunas cosas bsicas a la hora de modelizar el modelo de datos que usamos como
convenciones (nomenclatura, cosas as). Por ejemplo:
1. La clave primaria de las tablas siempre es un identificador autoincremental. Todas las
tablas tienen as un identificador interno, mantenido por el sistema. As, las claves ajenas
son ms fciles de mantener.
2. En general, nosotros no solemos poner campos requeridos preferimos hacer la
gestin dentro de la lgica de negocio. Nunca se sabe lo que te vas a encontrar, y se nos
han dado casos de campos de los que estbamos completamente seguros que eran
requeridos y hemos tenido que quitar la marca.
3. No se duplica informacin. Es decir, una de las reglas bsica es que la misma
informacin no puede estar en dos sitios, salvo
4. En muchos casos, creamos campos calculados, que permiten acceder de forma rpida
a informacin por ejemplo, el importe pendiente de un recibo, en realidad, se calcula
como el importe total del recibo menos la suma de los pagos parciales como hacer este
clculo cada vez que nos hace falta ralentiza el funcionamiento del sistema, hacemos un
campo calculado que se mantiene automticamente (en nuestro caso, a travs de Triggers
de la base de datos). La informacin est duplicada en dos sitios, s, pero por motivos de
rendimiento (y siempre est sincronizada).
5. En los nombres de los campos no ponemos caracteres especiales (ni acentos, ni
espacios, etc.). Aunque el gestor de base de datos lo admita, no lo hacemos, porque luego
nunca se sabe desde dnde vas a tener que acceder.

Descripcin de las entidades

El primer paso para hacer el modelo de datos es identificar las entidades (tablas) que vamos a
tener. Segn el caso de uso descrito, las tablas necesarias son las siguientes (al menos, son
las que nosotros usamos):
o Cursos: almacena la oferta formativa del centro. Representa el catlogo o folleto que
te dan al llegar al centro.
o Formas de Pago: para cada curso, las distintas opciones de pago que existen (es
parte del folleto tambin). Trimestral, mensual, anual, etc.
o Grupos: dentro de cada curso, los diferentes horarios a los que se puede asistir. En
este caso, el modelo que utilizamos es bastante ms complejo que el que voy a describir
aqu en un artculo posterior lo describir en detalle.
o Clientes: el que paga puede ser el mismo que el alumno, pero tambin puede que
no.
o Medios de pago: Contiene los diferentes mtodos que los clientes pueden usar para
pagar (contado, domicilacin bancaria, etc), incluyendo las cuentas bancarias del cliente.
o Alumnos: la gente que va a clase. Los clientes pueden ser empresas (personas
jurdicas), los alumnos son personas fsicas. Un mismo cliente puede tener mltiples
alumnos.
o Matrculas: Refleja en qu curso nos matriculamos, las fechas, la forma de pago, etc.
De forma fsica, se refleja en el contrato que te dan para firmar.
o Recibos: almacena los recibos que el cliente tiene que pagar (o ha pagado) en el
centro.
o Pagos: esta tabla refleja los pagos que el cliente ha hecho (un recibo no
necesariamente se paga de una vez). Como antes, la gestin de recibos y pagos que
hacemos en realidad es ms compleja de lo que voy a describir aqu. En otro artculo har
una descripcin ms completa.
o Alumnos en grupos: refleja los alumnos que estn asignados a los distintos grupos.
El alumno puede cambiar de grupo, y no queremos perder esa informacin histrica, as
que necesitamos una tabla para gestionarlo.
Aqu puedes ver el modelo grficamente:

Con PK se marcan las claves primarias, y con FK, las claves ajenas algunas lneas se
cruzan. Las flechas indican que una tabla es hija de otra, con la punta de flecha apuntando al
padre.
Como puedes ver, slo estn indicados los campos que forman el modelo de datos las
claves primarias y las claves ajenas, que en cualquier caso deben estar ocultas al usuario
final. En la siguiente seccin describiremos los campos de cada tabla.

Campos para las entidades

Slo describir los campos ms importantes, y no incluir los campos de clave primaria y
ajena que se describen en el grfico.
Cursos
o nombre: varchar(100)
o descripcion: Memo. Se utilizar, en el contrato que se imprime para el cliente, para
hacer una descripcin larga del curso en el que el alumno se est matriculando. En uno de
 los sistemas que tenemos, en lugar de tener un campo memo, tenemos una tabla separada
en la que se guardan, por tipologas, distintos campos memo, que se imprimen en distintos
lugares del contrato.
o fecha_inicio: date
o fecha_fin: date
Formas de pago
o nombre: varchar(100)
o importe: float. Es el importe de cada recibo que se cobrar
o numero_meses: integer. El nmero de meses de cada recibo. Si es 1, se crear un
recibo cada mes mientras dure la matriculacin, si es 3, uno cada tres meses, etc. En algn
sistema hemos hecho, en lugar de esto, una estructura de plantillas de recibos, con fechas,
descripciones, etc. personalizadas. Eso permite ms flexibilidad y ms control, pero el
modelo es bastante ms complejo.
o numero_orden: integer. A la hora de presentrselo al cliente, poder mostrar primero las
que ms nos interesen.
o importe_matricula: float. Si adems del importe del curso hay un importe de matrcula,
se marca aqu.
o concepto_matricula. El concepto del recibo de matrcula, si creamos uno.
Grupos
o nombre: varchar(100)
o codigo: varchar(20). Siempre viene bien tener una codificacin adems del nombre.
Por ejemplo, en algunos sistemas lo utilizamos para guardar el cdigo del grupo en la
Fundacin Tripartita.
o fecha_inicio: date
o fecha_fin: date. Por defecto, las del curso al que pertenece el grupo, y adems estas
fechas no pueden estar fuera de las fechas del curso al que pertenecen.
o lugar: varchar(100) de imparticin del grupo. En general, hacemos una gestin de
aulas, pero eso lo ampliar en otro artculo.
o notas: memo, del grupo
o horario: varchar(100) del grupo. En realidad, el horario se trata como una tabla por
debajo de esta, pero no voy a entrar en tanto nivel de detalle ahora.
o maximo_alumnos: Integer. Mximo nmero de alumnos permitidos en el grupo.
o numero_alumnos: Integer. Es el nmero de alumnos existentes en el grupo. Este
campo es de slo lectura para el usuario, y es calculado, a travs de una serie de Triggers
en la base de datos, para poder saber rpidamente el nmero de alumnos activos en cada
grupo sin tener que estar sumando.
Clientes
o nombre: varchar(100). En nuestros sistemas, normalmente, este es el nico campo
requerido (por cdigo, no en la base) que tenemos. As, el usuario puede dar de alta el
registro aunque no tenga todos los datos, y volver despus.
o primer_apellido: varchar(100)
o segundo_apellido: varchar(100)
o nombre_completo: varchar(300): Esto es un campo calculado, que se mantiene con
Triggers, para poder coger de forma rpida el conjunto Nombre+ +primer_apellido+
+segundo_apellido
o direccion: memo
o codigo_postal: varchar(20): no hay que ser tacao de vez en cuando hay que meter
una direccin extranjera y el cdigo postal puede ser ms grande.
o poblacion: varchar(50)
o notas_internas: memo
o etc. de datos personales (profesin, telfonos, email, etc.)
Alumnos
o nombre: varchar(100). Lo mismo que en clientes, pero lo requerido es nombre y primer
apellido (en clientes es slo nombre por si
o primer_apellido: varchar(100)
o segundo_apellido: varchar(100)
o nombre_completo: varchar(300):
o etc. de datos personales (profesin, telfonos, email, etc.)
Medios de pago
o tipo_medio: Integer. Normalmente tiene una tabla asociada con los tipos de medios de
pago, que suelen ser: Sin Pago, Contado, Banco
o nombre_titular: varchar(100)
o direccion_titular: memo
o entidad: varchar(4)
o oficina: varchar(4)
o dc: varchar(2)
o numero_cuenta: varchar(10). Si el tipo_medio es banco, entonces se tiene que rellenar
la informacin bancaria del cliente.
o por_defecto: boolean. Se suele preguntar el medio de pago, pero teniendo uno por
defecto, para no tener que rellenarlo siempre. Normalmente, cada cliente, al crearse, se
crea un medio de pago contado, y se le pone por defecto.
Matrculas
Adems de los datos de curso, forma de pago, medio de pago, alumno y cliente (esto ltimo
puede parecer redundante, pero no lo es podemos tener el caso (yo lo he visto) de un
alumno que se matricula para estudiar, digamos, ingls y francs el ingls lo paga el padre y
el francs la madre. As, es necesario que cada matrcula est asociada con el alumno, y
tambin con el cliente), necesitamos los siguientes campos:
o fecha_inicio: date.
o fecha_fin: date. Por defecto, las del curso, pero hay gente que puede matricularse
despus o terminar antes (si se da de baja, por ejemplo).
o importe: real. Por defecto, el de la forma de pago escogida, pero puede ser tambin
distinto descuentos por familiares, cosas as. Suele ser buena idea dejarlo abierto, para
que el cliente lo pueda cambiar.
o motivo_baja: varchar(100). Normalmente, los motivos de baja son una tabla separada,
para luego poder obtener estadsticas de nmero de bajas por tipo, cosas as.
Recibos
o fecha_emision: date
o fecha_cobro_completo: date
o numero_recibo: varchar(20)
o concepto: varchar(50)
o importe_recibo: float.
o importe_pendiente: float. Es un campo de slo lectura, actualizado a travs de triggers,
que permite acceder a la informacin sin tener que sumar.
Pagos
o fecha: date
o importe: real
o forma_cobro: varchar(20). Normalmente es una tabla separada, igual que el caso de
los tipos de baja. Puede ser: contado, transferencia, tarjeta, taln, etc.
Alumnos en grupos
o fecha_inicio: date
o fecha_fin: date. Suele ser una interseccin entre la duracin del grupo y la de la
matrcula, pero cuando el alumno cambia de grupo, para una matrcula puede haber varios
registros de alumnos en grupos. Hay que tener en cuenta tambin la posibilidad de que en
un mismo curso, pagando ms, un alumno pueda asistir a varios grupos.