Está en la página 1de 8

Modelo entidad-relacin, un ejemplo prctico (I.

Matriculacin)
marzo 29, 2010 en General, Procesos
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. En este artculo voy a intentar
explicar, con un ejemplo prctico, un buen modelado de datos.
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.
Voy a explicar en este artculo 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. De paso, 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):
Cursos: almacena la oferta formativa del centro. Representa el catlogo o folleto que

te dan al llegar al centro.


Formas de Pago: para cada curso, las distintas opciones de pago que existen (es

parte del folleto tambin). Trimestral, mensual, anual, etc.


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.
Clientes: el que paga puede ser el mismo que el alumno, pero tambin puede que

o
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.

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.

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.

Recibos: almacena los recibos que el cliente tiene que pagar (o ha pagado) en el
centro.

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.

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 podis ver el modelo grficamente:

Con PK se marcan las claves primarias, y con FK, las claves ajenas algunas lneas se
cruzan, no lo puedo evitar. Las flechas indican que una tabla es hija de otra, con la punta de
flecha apuntando al padre.
Como podis 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)

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.

fecha_inicio: date

fecha_fin: date

Formas de pago
o

nombre: varchar(100)

importe: float. Es el importe de cada recibo que se cobrar

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.

numero_orden: integer. A la hora de presentrselo al cliente, poder mostrar primero las


que ms nos interesen.

importe_matricula: float. Si adems del importe del curso hay un importe de matrcula,
se marca aqu.

concepto_matricula. El concepto del recibo de matrcula, si creamos uno.

Grupos
o

nombre: varchar(100)

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.

fecha_inicio: date

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.

lugar: varchar(100) de imparticin del grupo. En general, hacemos una gestin de


aulas, pero eso lo ampliar en otro artculo.

notas: memo, del grupo

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.

maximo_alumnos: Integer. Mximo nmero de alumnos permitidos en el grupo.

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.

primer_apellido: varchar(100)

segundo_apellido: varchar(100)

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

direccion: memo

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.

poblacion: varchar(50)

notas_internas: memo

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

primer_apellido: varchar(100)

segundo_apellido: varchar(100)

nombre_completo: varchar(300):

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

nombre_titular: varchar(100)

direccion_titular: memo

entidad: varchar(4)

oficina: varchar(4)

dc: varchar(2)

numero_cuenta: varchar(10). Si el tipo_medio es banco, entonces se tiene que rellenar


la informacin bancaria del cliente.

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 parece 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.

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).

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.

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

fecha_cobro_completo: date

numero_recibo: varchar(20)

concepto: varchar(50)

importe_recibo: float.

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

importe: real

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

fecha_inicio: date

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 (esto tambin lo
he visto).

Triggers y procedimientos almacenados


El modelo de datos y la lgica del negocio estn muy estrechamente relacionados. Los
sistemas de base de datos nos permiten desarrollar triggers y procedimientos almacenados, lo
que es muy conveniente para dejar trozos de la lgica de negocio asociados con la base de
datos, tanto por motivos de organizacin del cdigo como por motivos de rendimiento (un
procedimiento almacenado es varios rdenes de magnitud ms rpido que hacer el mismo
proceso a travs de un lenguaje de programacin).
En el ejemplo que estoy describiendo, hay varios triggers y procedimientos que se usan:
o

Actualizacin de los campos NombreCompleto de alumnos y clientes: normalmente,


es un trigger BEFORE INSERT y BEFORE UPDATE, que actualiza el campo en base al
contenido del nombre y los apellidos.

Actualizacin del campo ImportePagado de recibos, AFTER INSERT, UPDATE y


DELETE de pagos, que actualiza el campo ImportePendiente de recibos como la suma de
los pagos de ese recibo.

Es habitual hacer un procedimiento CREARRECIBOS, que se ejecuta en el proceso


de creacin de la matrcula (o un trigger AFTER INSERT), que crea los recibos de la
matrcula en base al importe y forma de pago seleccionadas.

En las prximas semanas continuar esta serie de artculos, describiendo otros submodelos
de sistemas que hemos desarrollado algunas ideas que tengo:
1.

Gestin de horarios y citas

2.

Facturacin

3.

Gestin de horas trabajadas

4.

Stock

Cualquier otra idea ser bienvenida

También podría gustarte